exec: Allocate code_gen_prologue from code_gen_buffer
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: Richard Henderson <rth@twiddle.net> Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
exec: Do not use absolute address hints for code_gen_buffer with -fpie
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: Richard Henderson <rth@twiddle.net> Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Eduardo Habkost [Mon, 15 Oct 2012 20:22:02 +0000 (17:22 -0300)]
create struct for machine initialization arguments
This should help us to:
- More easily add or remove machine initialization arguments without
having to change every single machine init function;
- More easily make mechanical changes involving the machine init
functions in the future;
- Let machine initialization forward the init arguments to other
functions more easily.
This change was half-mechanical process: first the struct was added with
the local ram_size, boot_device, kernel_*, initrd_*, and cpu_model local
variable initialization to all functions. Then the compiler helped me
locate the local variables that are unused, so they could be removed.
Michael Roth [Mon, 8 Oct 2012 20:45:49 +0000 (15:45 -0500)]
tci: fix build breakage for target-sparc
commit c28ae41 introduced GETPC() usage for sparc, which is currently
not defined when building with --enable-tcg-interpreter. Add sparc to
the list of targets we selectively define GETPC() for.
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: Stefan Weil <sw@weilnetz.de> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Jan Kiszka [Wed, 17 Oct 2012 17:09:25 +0000 (19:09 +0200)]
configure: Fix CONFIG_QEMU_HELPERDIR generation
We need to evaluate $libexecdir in configure, otherwise we literally end
up with "${prefix}/libexec" instead of the absolute path as
CONFIG_QEMU_HELPERDIR.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Peter Maydell [Thu, 4 Oct 2012 15:22:01 +0000 (16:22 +0100)]
qemu-options.hx: Change from recommending '?' to 'help'
Update the -help output and documentation so that it recommends
'help' rather than '?' for the various "list valid values for this
option" cases. '?' is deprecated (as it can fail confusingly if
not quoted), so it's better to steer users towards 'help'. ('?'
still works, for backwards compatibility.)
This is the -help option part of the change otherwise done in
commit c8057f9, since we are now past release 1.2 and free to
change our help text without worrying about breaking libvirt.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Aurelien Jarno [Fri, 19 Oct 2012 18:18:44 +0000 (20:18 +0200)]
Merge branch 'trivial-patches' of git://github.com/stefanha/qemu
* 'trivial-patches' of git://github.com/stefanha/qemu:
ui/vnc-jobs.c: Fix minor typos in comments
net/tap-win32: Fix compiler warning caused by missing include statement
configure: Remove unused parameters from main function
target-arm/neon_helper: Remove obsolete FIXME comment
targphys.h: Don't define target_phys_addr_t for user-mode emulators
ui/vnc: Only report/use TIGHT_PNG encoding if enabled.
Peter Maydell [Fri, 12 Oct 2012 17:59:44 +0000 (18:59 +0100)]
targphys.h: Don't define target_phys_addr_t for user-mode emulators
Commit 4be403c accidentally defined the target_phys_addr_t type when
building user-mode emulators. Since the type doesn't really make
any sense except for system emulators, avoid defining it when building
in user mode.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Andreas Färber <afaerber@suse.de> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Joel Martin [Wed, 16 May 2012 12:54:25 +0000 (12:54 +0000)]
ui/vnc: Only report/use TIGHT_PNG encoding if enabled.
If TIGHT_PNG is not enabled by the --enable-vnc-png configure flag
then do not report to the client that it is supported.
Also, since TIGHT_PNG is the same as the TIGHT encoding but with the
filter/copy replaced with PNG data, adding it to the supported
encodings list when it is disabled will cause the TIGHT encoding to be
used even though the client requested TIGHT_PNG.
Signed-off-by: Joel Martin <github@martintribe.org> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Instructions that both use the RRX second operand and update CS were
incorrect, as the Carry flag was updated too early. An example of such an
instruction would be:
ands r12,r13,RRX
Ands, because of the "s" flag will update the carry flag. But the RRX second
operand rotates through the C flag which should happen before the update.
Fixed the ordering of the two, the old carry is read by "r13,RRX" before being
updated.
Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com> Reported-by: Vinesh Peringat <vineshp@xilinx.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Juan Quintela [Wed, 29 Aug 2012 17:03:09 +0000 (19:03 +0200)]
virtio-net: use qemu_get_buffer() in a temp buffer
qemu_fseek() is known to be wrong. Would be removed on the next
commit. This code should never been used (value has been
MAC_TABLE_ENTRIES since 2009).
Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Tue, 16 Aug 2011 23:43:24 +0000 (16:43 -0700)]
BufferedFile: append, then flush
Simplify the logic for pushing data from the buffer to the output
pipe/socket. This also matches more closely what will be the
operation of the migration thread.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Orit Wasserman <owasserm@redhat.com>
Juan Quintela [Fri, 20 Jul 2012 10:33:00 +0000 (12:33 +0200)]
Separate migration bitmap
This patch creates a migration bitmap, which is periodically kept in
sync with the qemu bitmap. A separate copy of the dirty bitmap for the
migration limits the amount of concurrent access to the qemu bitmap
from iothread and migration thread (which requires taking the big
lock).
We use the qemu bitmap type. We have to "undo" the dirty_pages
counting optimization on the general dirty bitmap and do the counting
optimization with the migration local bitmap.
Signed-off-by: Umesh Deshpande <udeshpan@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
movcond d, c1, c2, const, s
to
movcond d, c1, c2, s, const
It also prefers
add r, r, c
over
add r, c, r
when both inputs are known constants. This doesn't matter for true add, as
we will fully constant fold that. But it matters for a follow-on patch using
this routine for add2 which may not be fully foldable.
Signed-off-by: Richard Henderson <rth@twiddle.net> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Avi Kivity [Wed, 17 Oct 2012 15:14:41 +0000 (17:14 +0200)]
memory: abort if a memory region is destroyed during a transaction
Destroying a memory region is illegal within a transaction, as until
the transaction is committed, the memory core may hold references to
the region. Add an assert to check for violations of this rule.
Avi Kivity [Wed, 17 Oct 2012 15:10:04 +0000 (17:10 +0200)]
i440fx: avoid destroying memory regions within a transaction
Calling memory_region_destroy() within a transaction is illegal, since
the memory API is allowed to continue to dispatch to a region until the
transaction commits. 440fx does that however when managing PAM registers.
This bug is benign, since the regions are all aliases (which the memory
core tends to throw anyway), and since we don't do concurrent dispatch yet,
but instead of relying on that, tighten ship ahead of the coming concurrency
storm.
Fix by having a predefined set of regions, of which one will be enabled at
any time.
Alexander Graf [Mon, 15 Oct 2012 18:30:28 +0000 (20:30 +0200)]
memory: Make eventfd adhere to device endianness
Our memory API MMIO regions know the concept of device endianness. This
is used to automatically swap endianness between devices and host CPU,
depending on whether buses in between would swizzle the bits.
The ioeventfd value comparison does not adhere to that semantic though.
Probably because nobody has been running ioeventfd on a BE platform and
the only device implementing ioeventfd right now is LE (PCI) based.
So add swizzling to ioeventfd registration / deletion to make the rest
of the code as consistent as possible.
Thanks a lot to Michael Tsirkin to point me towards the right direction.
Signed-off-by: Alexander Graf <agraf@suse.de> Signed-off-by: Avi Kivity <avi@redhat.com>
Note that in the general reg=reg,reg case we're restricted
to 16-bit insertions. This makes it easy to allow "any"
constant as input, as post-truncation it will fit into the
constant load insn for which we have room in the bundle.
Signed-off-by: Richard Henderson <rth@twiddle.net> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
projects / qemu.git / log