get_system_io() returns the root I/O memory region.
Reviewed-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Use mmap to allocate executable memory on NetBSD as well.
Signed-off-by: NChristoph Egger <Christoph.Egger@amd.com>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Do not allocate TCG-only resources like the translation buffer when
running over KVM or XEN. Saves a "few" bytes in the qemu address space
and is also conceptually cleaner.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

When trying to map an alias of a ram region, where the alias starts at
address A and we map it into address B, and A > B, we had an arithmetic
underflow.  Because we use unsigned arithmetic, the underflow converted
into a large number which failed addrrange_intersects() tests.

The concrete example which triggered this was cirrus vga mapping
the framebuffer at offsets 0xc0000-0xc7fff (relative to the start of
the framebuffer) into offsets 0xa0000 (relative to system addres space
start).

With our favorite analogy of a windowing system, this is equivalent to
dragging a subwindow off the left edge of the screen, and failing to clip
it into its parent window which is on screen.

Fix by switching to signed arithmetic.
Signed-off-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Allocate the root memory region and initialize it.
Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

In Xen case, memory can be bigger than the host memory. that mean a
32bits host (and QEMU) should be able to handle a RAM address of 64bits.
Signed-off-by: NAnthony PERARD <anthony.perard@citrix.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

As the variable pd and addr1 inside the function cpu_physical_memory_rw
are mean to handle a RAM address, they should be of the ram_addr_t type
instead of unsigned long.
Signed-off-by: NAnthony PERARD <anthony.perard@citrix.com>
Acked-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

cea5f9a2 exposed bugs in unassigned memory
access handling. Fix them by always passing CPUState to the handlers.
Reported-by: NHervé Poussineau <hpoussin@reactos.org>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

qemu_ram_ptr_length should take ram_addr_t as argument rather than
target_phys_addr_t because is doing comparisons with RAMBlock addresses.

cpu_physical_memory_map should create a ram_addr_t address to pass to
qemu_ram_ptr_length from PhysPageDesc phys_offset.

Remove code after abort() in qemu_ram_ptr_length.

Changes in v2:

- handle 0 size in qemu_ram_ptr_length;

- rename addr1 to raddr;

- initialize raddr to ULONG_MAX.
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Xen won't be enabled if there is no backend support available for the
host. And that also means the map cache will work. So drop the separate
config switch and move the required stubs over to xen-stub.c.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

The map cache is a Xen thing, so its API should make this clear.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

When calculating the point at which we should not try to put another
TB into the code gen buffer, we have to allow not just for OPC_MAX_SIZE
but OPC_BUF_SIZE. This is because the target translate.c will only
stop when an instruction has put it past the OPC_MAX_SIZE limit, so
we have to include the MAX_OP_PER_INSTR margin which that final insn
might have used.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Device code some times needs to access physical memory and does that
through the ld./st._phys functions. However, these are the exact same
functions that the CPU uses to access memory, which means they will
be endianness swapped depending on the target CPU.

However, devices don't know about the CPU's endianness, but instead
access memory directly using their own interface to the memory bus,
so they need some way to read data with their native endianness.

This patch adds _le and _be functions to ld./st._phys.
Signed-off-by: NAlexander Graf <agraf@suse.de>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Most exec-all.h include directives are now useless, remove them.
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Once there, use a better variable name.
Signed-off-by: NJuan Quintela <quintela@redhat.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>

Use qemu_invalidate_entry in cpu_physical_memory_unmap.

Do not lock mapcache entries in qemu_get_ram_ptr if the address falls in
the ramblock with offset == 0. We don't need to do that because the
callers of qemu_get_ram_ptr either try to map an entire block, other
from the main ramblock, or until the end of a page to implement a single
read or write in the main ramblock.
If we don't lock mapcache entries in qemu_get_ram_ptr we don't need to
call qemu_invalidate_entry in qemu_put_ram_ptr anymore because we can
leave with few long lived block mappings requested by devices.

Also move the call to qemu_ram_addr_from_mapcache at the beginning of
qemu_ram_addr_from_host.
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Introduce qemu_ram_ptr_length that takes an address and a size as
parameters rather than just an address.

Refactor cpu_physical_memory_map so that we call qemu_ram_ptr_length only
once rather than calling qemu_get_ram_ptr one time per page.
This is not only more efficient but also tries to simplify the logic of
the function.
Currently we are relying on the fact that all the pages are mapped
contiguously in qemu's address space: we have a check to make sure that
the virtual address returned by qemu_get_ram_ptr from the second call on
is consecutive. Now we are making this more explicit replacing all the
calls to qemu_get_ram_ptr with a single call to qemu_ram_ptr_length
passing a size argument.
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: agraf@suse.de
CC: anthony@codemonkey.ws
Signed-off-by: NAlexander Graf <agraf@suse.de>

Replace xen_map_block with qemu_map_cache with the appropriate locking
and size parameters.
Replace xen_unmap_block with qemu_invalidate_entry.
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

There is no need for qemu_map_cache_unlock, just use
qemu_invalidate_entry instead.
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

When a phys memory client registers and we play catchup by walking
the page tables, we can make a huge improvement in the number of
times the set_memory callback is called by batching contiguous
pages together.  With a 4G guest, this reduces the number of callbacks
at registration from 1048866 to 296.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

This patch removes all references to signal.h when qemu-common.h is included
as they become redundant.
Signed-off-by: NAlexandre Raymond <cerbere@gmail.com>
Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>

Required for regions mapped via qemu_ram_alloc_from_ptr().  VFIO
and ivshmem will make use of this to remove mappings when devices
are hot unplugged.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

Signed-off-by: NRichard Henderson <rth@twiddle.net>

Signed-off-by: NStefan Weil <weil@mail.berlios.de>
Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>

While trying out the > 64GB guest RAM patch, I hit some virtual address
limitations of my host system, which resulted in mmap failing. Unfortunately,
qemu didn't tell me about this failure, but just used the NULL pointer
happily, resulting in either segmentation faults or other fun errors.

To spare other users from tracing this down, let's print a nice message
instead so the user can figure out what's wrong from there.
Signed-off-by: NAlexander Graf <agraf@suse.de>

the current s390x qemu memory layout is

0x1000000: guest start
0x80000000: qemu binary

which limits the amount of available memory to <2GB.
This patch moves the guest pages to 32GB to not collide with the binary
and to leave some space for the program break of qemu.
Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

This function allows to unlock a ram_ptr give by qemu_get_ram_ptr. After
a call to qemu_put_ram_ptr, the pointer may be unmap from QEMU when
used with Xen.
Signed-off-by: NAnthony PERARD <anthony.perard@citrix.com>
Acked-by: NAlexander Graf <agraf@suse.de>
Signed-off-by: NAlexander Graf <agraf@suse.de>

On IA32 host or IA32 PAE host, at present, generally, we can't create
an HVM guest with more than 2G memory, because generally it's almost
impossible for Qemu to find a large enough and consecutive virtual
address space to map an HVM guest's whole physical address space.
The attached patch fixes this issue using dynamic mapping based on
little blocks of memory.

Each call to qemu_get_ram_ptr makes a call to qemu_map_cache with the
lock option, so mapcache will not unmap these ram_ptr.

Blocks that do not belong to the RAM, but usually to a device ROM or to
a framebuffer, are handled in a separate function. So the whole RAMBlock
can be map.
Signed-off-by: NJun Nakajima <jun.nakajima@intel.com>
Signed-off-by: NAnthony PERARD <anthony.perard@citrix.com>
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

When we're trying to get a newly registered phys memory client updated
with the current page mappings, we end up passing the region offset
(a ram_addr_t) as the start address rather than the actual guest
physical memory address (target_phys_addr_t).  If your guest has less
than 3.5G of memory, these are coincidentally the same thing.  If
there's more, the region offset for the memory above 4G starts over
at 0, so the set_memory client will overwrite it's lower memory entries.

Instead, keep track of the guest phsyical address as we're walking the
tables and pass that to the set_memory client.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

When we register a physical memory client, we try to walk the page
tables, calling the set_memory hook for every entry.  Effectively
playing catchup for the client for everything already registered.
With this type, we only walk the 2nd entry of the l1 table,
typically missing all of the registered memory.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

This allows to override the interrupt handling of QEMU in system mode.
KVM will make use of it to set a specialized handler.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

Both have only two lines in common, and we will convert the system
service into a callback which is of no use for user mode operation.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
CC: Riku Voipio <riku.voipio@iki.fi>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

The previous patch removed the need for parameter puc.
Is is now unused, so remove it.

Cc: Aurelien Jarno <aurelien@aurel32.net>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NStefan Weil <weil@mail.berlios.de>

Using cpu_physical_memory_read, cpu_physical_memory_write and ldub_phys
improves readability and allows removing some type casts.

lduw_phys and ldl_phys were not used because both require aligned
addresses. Therefore it is not possible to simply replace existing
calls by one of these functions.
Signed-off-by: NStefan Weil <weil@mail.berlios.de>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

All other type casts in calls of cpu_physical_memory_write are
used by hardware emulations and will be fixed by separate patches.

Cc: Blue Swirl <blauwirbel@gmail.com>
Signed-off-by: NStefan Weil <weil@mail.berlios.de>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

Signed-off-by: NEdgar E. Iglesias <edgar.iglesias@gmail.com>

Pass the flag to all cpu notifiers, doing
nothing at this point. Will be used by
follow-up patches.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Based on patch by Glauber Costa:

To allow management applications like libvirt to apply CPU affinities to
the VCPU threads, expose their ID via info cpus. This patch provides the
pre-existing and used interface from qemu-kvm.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

This both detects invalid invocations of qemu_ram_free and
qemu_ram_remap when mem_path is non-NULL and fixes a build error on
s390 ("'area' may be used uninitialized in this function").
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
CC: Alexander Graf <agraf@suse.de>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

qemu_ram_remap() unmaps the specified RAM pages, then re-maps these
pages again.  This is used by KVM HWPoison support to clear HWPoisoned
page tables across guest rebooting, so that a new page may be
allocated later to recover the memory error.

[ Jan: style fixlets, WIN32 fix ]
Signed-off-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>