This is not needed since the RAM list is not modified anymore by
qemu_get_ram_ptr.  Replace it with qemu_get_ram_block.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

phys_mem_alloc and its assigned values qemu_anon_ram_alloc and
legacy_s390_alloc must have identical argument lists.

legacy_s390_alloc uses the size parameter to call mmap, so size_t is
good enough for all of them.

This patch fixes compiler errors on i686 Linux hosts:

  CC    alpha-softmmu/exec.o
exec.c:752:51: error:
 initialization from incompatible pointer type [-Werror]
exec.c: In function 'qemu_ram_alloc_from_ptr':
exec.c:1139:32: error:
 comparison of distinct pointer types lacks a cast [-Werror]
exec.c: In function 'qemu_ram_remap':
exec.c:1283:21: error:
 comparison of distinct pointer types lacks a cast [-Werror]
Signed-off-by: NStefan Weil <sw@weilnetz.de>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Message-id: 1380481005-32399-1-git-send-email-sw@weilnetz.de
Signed-off-by: NAnthony Liguori <aliguori@amazon.com>

It is only used there and is deemed very fragile if not incorrect in its
current memcpy() form. Moving it into linux-user will allow to move
parts into target_cpu.h headers and only copy what the ABI mandates.
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Touched some error after enabling DEBUG_SUBPAGE.
Signed-off-by: NAmos Kong <akong@redhat.com>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

Commit 3435f395 reduced the ifdeffery with
this result for MinGW:

exec.c: In function ‘qemu_ram_free’:
exec.c:1239:17: warning:
 implicit declaration of function ‘munmap’ [-Wimplicit-function-declaration]
exec.c:1239:17: warning:
 nested extern declaration of ‘munmap’ [-Wnested-externs]
exec.c:1239: undefined reference to `munmap'

Add some ifdeffery again to fix this.
Signed-off-by: NStefan Weil <sw@weilnetz.de>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

MADV_DONTFORK prevents fork to fail with -ENOMEM if the default
overcommit heuristics decides there's too much anonymous virtual
memory allocated. If the KVM secondary MMU is synchronized with MMU
notifiers or not, doesn't make a difference in that regard.

Secondly it's always more efficient to avoid copying the guest
physical address space in the fork child (so we avoid to mark all the
guest memory readonly in the parent and so we skip the establishment
and teardown of lots of pagetables in the child).

In the common case we can ignore the error if MADV_DONTFORK is not
available. Leave a second invocation that errors out in the KVM path
if MMU notifiers are missing and KVM is enabled, to abort in such
case.
Signed-off-by: NAndrea Arcangeli <aarcange@redhat.com>
Tested-By: NBenoit Canet <benoit@irqsave.net>
Acked-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NGleb Natapov <gleb@redhat.com>

We abort() on memory allocation failure.  abort() is appropriate for
programming errors.  Maybe most memory allocation failures are
programming errors, maybe not.  But guest memory allocation failure
isn't, and aborting when the user asks for more memory than we can
provide is not nice.  exit(1) instead, and do it in just one place, so
the error message is consistent.
Tested-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NAndreas Färber <afaerber@suse.de>
Acked-by: NLaszlo Ersek <lersek@redhat.com>
Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Message-id: 1375276272-15988-8-git-send-email-armbru@redhat.com
Signed-off-by: NAnthony Liguori <anthony@codemonkey.ws>

Another issue missed in commit fdec9918 is -mem-path: it needs to be
rejected only for old S390 KVM, not for any S390.  Not that I
personally care, but the ifdeffery in qemu_ram_alloc_from_ptr() annoys
me.

Note that this doesn't actually make -mem-path work, as the kernel
doesn't (yet?)  support large pages in the host for KVM guests.  Clean
it up anyway.

Thanks to Christian Borntraeger for pointing out the S390 kernel
limitations.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Acked-by: NLaszlo Ersek <lersek@redhat.com>
Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Message-id: 1375276272-15988-7-git-send-email-armbru@redhat.com
Signed-off-by: NAnthony Liguori <anthony@codemonkey.ws>

Old S390 KVM wants guest RAM mapped in a peculiar way.  Commit 6b02494d
implemented that.

When qemu_ram_remap() got added in commit cd19cfa2, its code carefully
mimicked the allocation code: peculiar way if defined(TARGET_S390X) &&
defined(CONFIG_KVM), else normal way.

For new S390 KVM, we actually want the normal way.  Commit fdec9918
changed qemu_ram_alloc_from_ptr() accordingly, but forgot to update
qemu_ram_remap().  If qemu_ram_alloc_from_ptr() maps RAM the normal
way, but qemu_ram_remap() remaps it the peculiar way, remapping
changes protection and flags, which it shouldn't.

Fortunately, this can't happen, as we never remap on S390.

Replace the incorrect code with an assertion.

Thanks to Christian Borntraeger for help with assessing the bug's
(non-)impact.
Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Acked-by: NLaszlo Ersek <lersek@redhat.com>
Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-id: 1375276272-15988-6-git-send-email-armbru@redhat.com
Signed-off-by: NAnthony Liguori <anthony@codemonkey.ws>

Make it a generic hook rather than a KVM hook.  Less code and
ifdeffery.

Since the only user of the hook is old S390 KVM, there's hope we can
get rid of it some day.
Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Acked-by: NLaszlo Ersek <lersek@redhat.com>
Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-id: 1375276272-15988-5-git-send-email-armbru@redhat.com
Signed-off-by: NAnthony Liguori <anthony@codemonkey.ws>

Instead of spreading its ifdeffery everywhere, confine it to
qemu_ram_alloc_from_ptr().  Everywhere else, simply test block->fd,
which is non-negative exactly when block uses -mem-path.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Acked-by: NLaszlo Ersek <lersek@redhat.com>
Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-id: 1375276272-15988-4-git-send-email-armbru@redhat.com
Signed-off-by: NAnthony Liguori <anthony@codemonkey.ws>

With -mem-path, qemu_ram_alloc_from_ptr() first tries to allocate
accordingly, but when it fails, it falls back to normal allocation.

The fall back allocation code used to be effectively identical to the
"-mem-path not given" code, until it started to diverge in commit
432d268c.  I believe the code still works, but clean it up anyway: drop
the special fall back allocation code, and fall back to the ordinary
"-mem-path not given" code instead.
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Acked-by: NLaszlo Ersek <lersek@redhat.com>
Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-id: 1375276272-15988-3-git-send-email-armbru@redhat.com
Signed-off-by: NAnthony Liguori <anthony@codemonkey.ws>

Issues:

* We try to obey -mem-path even though it can't work with Xen.

* To implement -machine mem-merge, we call
  memory_try_enable_merging(new_block->host, size).  But with Xen,
  new_block->host remains null.  Oops.

Fix by separating Xen allocation from normal allocation.
Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Acked-by: NLaszlo Ersek <lersek@redhat.com>
Message-id: 1375276272-15988-2-git-send-email-armbru@redhat.com
Signed-off-by: NAnthony Liguori <anthony@codemonkey.ws>

Signed-off-by: Nliguang <lig.fnst@cn.fujitsu.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Accesses to unassigned io ports shall return -1 on read and be ignored
on write. Ensure these properties via dedicated ops, decoupling us from
the memory core's handling of unassigned accesses.

Cc: qemu-stable@nongnu.org
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

If offset_within_address_space falls in a page, then we register a
subpage. So check offset_within_address_space rather than
offset_within_region.

Cc: qemu-stable@nongnu.org
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: "Andreas Färber" <afaerber@suse.de>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Blue Swirl <blauwirbel@gmail.com>
Signed-off-by: NHu Tao <hutao@cn.fujitsu.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

The problem is introduced by commit 23326164 (exec: Support 64-bit
operations in address_space_rw, 2013-07-08).  Before that commit,
memory_access_size would only return 1/2/4.

Since alignment is already handled above, reduce l to the largest
power of two that is smaller than l.

Cc: qemu-stable@nongnu.org
Reported-by: NOleksii Shevchuk <alxchk@gmail.com>
Tested-by: NOleksii Shevchuk <alxchk@gmail.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

It was introduced to loop over CPUs from target-independent code, but
since commit 182735ef target-independent
CPUState is used.

A loop can be considered more efficient than function calls in a loop,
and CPU_FOREACH() hides implementation details just as well, so use that
instead.
Suggested-by: NMarkus Armbruster <armbru@redhat.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Introduce CPU_FOREACH(), CPU_FOREACH_SAFE() and CPU_NEXT() shorthand
macros.
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Commit 1a1562f5 prepared a VMSTATE_CPU()
macro for device-style VMStateDescription registration, but missed to
adapt cpu_exec_init(), so that the "cpu_common" VMStateDescription was
still registered for AlphaCPU (fe31e737)
and OpenRISCCPU (da697214). Fix this.

Cc: Richard Henderson <rth@twiddle.net>
Tested-by: NJia Liu <proljc@gmail.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Passing a CPUState pointer instead of a CPUArchState pointer eliminates
the last target dependent data type in sysemu/kvm.h.

It also simplifies the code.
Signed-off-by: NStefan Weil <sw@weilnetz.de>
Acked-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

When a new thread gets created, we need to reset non arch specific state to
get the new CPU into clean state.

However this reset should happen before the arch specific CPU contents get
copied over. Otherwise we end up having clean reset state in our newly created
thread.
Signed-off-by: NAlexander Graf <agraf@suse.de>
Signed-off-by: NRiku Voipio <riku.voipio@linaro.org>

Propagate X86CPU in kvmvapic for simplicity.
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Change breakpoint_invalidate() argument to CPUState alongside.

Since all targets now assign a softmmu-only field, we can drop helpers
cpu_class_set_{do_unassigned_access,vmsd}() and device_class_set_vmsd().

Prepares for changing cpu_memory_rw_debug() argument to CPUState.

Acked-by: Max Filippov <jcmvbkbc@gmail.com> (for xtensa)
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Use CPUState::env_ptr for now.

Needed for GdbState::c_cpu.
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Prepares for changing cpu_single_step() argument to CPUState.

Acked-by: Michael Walle <michael@walle.cc> (for lm32)
Signed-off-by: NAndreas Färber <afaerber@suse.de>

access_size_min can be 1 because erroneous accesses must not crash
QEMU, they should trigger exceptions in the guest or just return
garbage (depending on the CPU).  I am not sure I understand the
comment: placing a 4-byte field at the last byte of a region
makes no sense (unless impl.unaligned is true), and that is
why memory.c:access_with_adjusted_size does not bother with
minimums larger than the remaining length.

access_size_max can be mr->ops->valid.max_access_size because memory.c
can and will still break accesses bigger than
mr->ops->impl.max_access_size.
Reported-by: NMarkus Armbruster <armbru@redhat.com>
Tested-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Commit e3127ae0 introduced a problem where we're passing a
hwaddr* to qemu_ram_ptr_length() but it wants a ram_addr_t*;
this will cause problems on 32 bit hosts and in any case
provokes a clang warning on MacOSX:

  CC    arm-softmmu/exec.o
exec.c:2164:46: warning: incompatible pointer types passing 'hwaddr *'
(aka 'unsigned long long *') to parameter of type 'ram_addr_t *'
(aka 'unsigned long *')
[-Wincompatible-pointer-types]
    return qemu_ram_ptr_length(raddr + base, plen);
                                             ^~~~
exec.c:1392:63: note: passing argument to parameter 'size' here
static void *qemu_ram_ptr_length(ram_addr_t addr, ram_addr_t *size)
                                                              ^

Since this function is only used in one place, change its
prototype to pass a hwaddr* rather than a ram_addr_t*,
rather than contorting the calling code to get the type right.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Tested-by: NRiku Voipio <riku.voipio@linaro.org>
Tested-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Honor the implementation maximum access size, and at least check
the minimum access size.
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NRichard Henderson <rth@twiddle.net>

Since commit 878096ee (cpu: Turn
cpu_dump_{state,statistics}() into CPUState hooks) CPUArchState is no
longer needed.

Add documentation and make the functions available through qemu/log.h
outside NEED_CPU_H to allow use in qom/cpu.c. Moving them to qom/cpu.h
was not yet possible due to convoluted include paths, so that some
devices grow an implicit and unneeded dependency on qom/cpu.h for now.

Acked-by: Michael Walle <michael@walle.cc> (for lm32)
Reviewed-by: NRichard Henderson <rth@twiddle.net>
[AF: Simplified mb_cpu_do_interrupt() and do_interrupt_all() changes]
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Move next_cpu from CPU_COMMON to CPUState.
Move first_cpu variable to qom/cpu.h.

gdbstub needs to use CPUState::env_ptr for now.
cpu_copy() no longer needs to save and restore cpu_next.
Acked-by: NPaolo Bonzini <pbonzini@redhat.com>
[AF: Rebased, simplified cpu_copy()]
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Move it to qom/cpu.h.
Signed-off-by: NAndreas Färber <afaerber@suse.de>

The previous two commits fixed bugs in -machine option queries.  I
can't find fault with the remaining queries, but let's use
qemu_get_machine_opts() everywhere, for consistency, simplicity and
robustness.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Message-id: 1372943363-24081-7-git-send-email-armbru@redhat.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

It seems to be unused since several years (commit
be995c27 in 2006).
Signed-off-by: NStefan Weil <sw@weilnetz.de>
Reviewed-by: NAndreas Färber <afaerber@suse.de>
Message-id: 1373044036-14443-1-git-send-email-sw@weilnetz.de
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Reviewed-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

cur_map is not used anymore; instead, each AddressSpaceDispatch
has its own nodes/sections pair.  The priorities of the
MemoryListeners, and in the future RCU, guarantee that the
nodes/sections are not freed while they are still in use.

(In fact, next_map itself is not needed except to free the data on the
next update).

To avoid incorrect use, replace cur_map with a temporary copy that
is only valid while the topology is being updated.  If you use it,
the name prev_map makes it clear that you're doing something weird.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

After this patch, AddressSpaceDispatch holds a constistent tuple of
(phys_map, nodes, sections).  This will be important when updates
of the topology will run concurrently with reads.

cur_map is not used anymore except for freeing it at the end of the
topology update.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

This same treatment previously done to phys_node_map and phys_sections
is now applied to the dispatch field of AddressSpace.  Topology updates
use as->next_dispatch while accesses use as->dispatch.
Reviewed-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

This will help having two copies of AddressSpaceDispatch during the
recreation of the radix tree (one being built, and one that is complete
and will be protected by RCU).  We do not want to have to unregister and
re-register the listener.
Reviewed-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Currently, phys_node_map and phys_sections are shared by all
of the AddressSpaceDispatch.  When updating mem topology, all
AddressSpaceDispatch will rebuild dispatch tables sequentially
on them.  In order to prepare for RCU access, leave the old
memory map alive while the next one is being accessed.

When rebuilding, the new dispatch tables will build and lookup
next_map; after all dispatch tables are rebuilt, we can switch
to next_* and free the previous table.

Based on a patch from Liu Ping Fan.
Signed-off-by: NLiu Ping Fan <qemulist@gmail.com>
Reviewed-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>