When we added the _with_attrs accessors we forgot to mention
them in the documentation.
Backports commit 687ac05d71bbb3172e0546248e40483ef43a4813 from qemu
Now that all the users of old_mmio MemoryRegion accessors
have been converted, we can remove the core code support.
Backports commit 62a0db942dec6ebfec19aac2b604737d3c9a2d75 from qemu
Memory regions configured as DEVICE_BIG_ENDIAN (or DEVICE_NATIVE_ENDIAN on
big-endian guest) behave incorrectly when the memory access 'size' is smaller
than the implementation 'access_size'.
In the following code segment from access_with_adjusted_size():
if (memory_region_big_endian(mr)) {
for (i = 0; i < size; i += access_size) {
r |= access_fn(mr, addr + i, value, access_size,
(size - access_size - i) * 8, access_mask, attrs);
}
(size - access_size - i) * 8 is the number of bits that will arithmetic
shift the current value.
Currently we can only 'left' shift a read() access, and 'right' shift a write().
When the access 'size' is smaller than the implementation, we get a negative
number of bits to shift.
For the read() case, a negative 'left' shift is a 'right' shift :)
However since the 'shift' type is unsigned, there is currently no way to
right shift.
Fix this by changing the access_fn() prototype to handle signed shift values,
and modify the memory_region_shift_read|write_access() helpers to correctly
arithmetic shift the opposite direction when the 'shift' value is negative.
This patch fixes the checking of boundary crossing instructions.
In icount mode only first instruction of the block may cross
the page boundary to keep the translation deterministic.
These conditions already existed, but compared the wrong variable.
Backports commit 41d54dc09f1f327dedc79d5ba0b1b437ab7b0e94 from qemu
An interface can't have any instance size or callback, or itself
implement other interfaces (this is unsupported).
Backports commit 422ca1432f7b44f2a9f3ad94a65d36927da021fa from qemu
This flag will be used for KVM's nested VMX migration; the HF_GUEST_MASK name
is already used in KVM, adopt it in QEMU as well.
Backports commit f8dc4c645ec2956a6cd97e0ca0fdd4753181f735 from qemu
Interrupt handling depends on various flags in env->hflags or env->hflags2,
and the exact detail were not exactly replicated between x86_cpu_has_work
and x86_cpu_exec_interrupt. Create a new function that extracts the
highest-priority non-masked interrupt, and use it in both functions.
Backports commit 92d5f1a4147c3722b5e9a8bcfb7dc261b7a8b855 from qemu
if MemoryRegion intialization fails it's left in semi-initialized state,
where it's size is not 0 and attached as child to owner object.
And this leds to crash in following use-case:
(monitor) object_add memory-backend-file,id=mem1,size=99999G,mem-path=/tmp/foo,discard-data=yes
memory.c:2083: memory_region_get_ram_ptr: Assertion `mr->ram_block' failed
Aborted (core dumped)
it happens due to assumption that memory region is intialized when
memory_region_size() != 0
and therefore it's ok to access it in
file_backend_unparent()
if (memory_region_size() != 0)
memory_region_get_ram_ptr()
which happens when object_add fails and unparents failed backend making
file_backend_unparent() access invalid memory region.
Fix it by making sure that memory_region_init_foo() APIs cleanup externally
visible side effects on failure (like set size to 0 and unparenting object)
QEMU cannot pass through the breakpoints when 'si' command is used
in remote gdb. This patch disables inserting the breakpoints
when we are already single stepping though the gdb remote protocol.
This patch also fixes icount calculation for the blocks that include
breakpoints - instruction with breakpoint is not executed and shouldn't
be used in icount calculation.
Backports commit f9f1f56e4da088b993ce28775c271d5bcdcf49ae from qemu
The config.status script is auto-generated by configure upon
completion. The intention is that config.status can be later invoked by
the developer directly, or by make indirectly, to re-detect the same
environment that configure originally used.
The current config.status script, however, only contains a record of the
command line arguments to configure. Various environment variables have
an effect on what configure will find. In particular PKG_CONFIG_LIBDIR &
PKG_CONFIG_PATH vars will affect what libraries pkg-config finds. The
PATH var will affect what toolchain binaries and XXXX-config scripts are
found. The LD_LIBRARY_PATH var will affect what libraries are
found. Most commands have env variables that will override the name/path
of the default version configure finds.
All these key env variables should be recorded in the config.status script.
Autoconf would also preserve CFLAGS, LDFLAGS, LIBS, CPPFLAGS, but QEMU
deals with those differently, expecting extra flags to be set using
configure args, rather than env variables. At the end of the script we
also don't have the original values of those env vars, as we modify them
during configure.
Backports commit e811da7fe229cc17d98b230bdfeaf6d0631ea987 from qemu
The TCG backend uses LOWREGMASK to get the low 3 bits of register numbers.
This was defined as no-op for 32-bit x86, with the assumption that we have
eight registers anyway. This assumption is not true once we have xmm regs.
Since LOWREGMASK was a no-op, xmm register indidices were wrong in opcodes
and have overflown into other opcode fields, wreaking havoc.
To trigger these problems, you can try running the "movi d8, #0x0" AArch64
instruction on 32-bit x86. "vpxor %xmm0, %xmm0, %xmm0" should be generated,
but instead TCG generated "vpxor %xmm0, %xmm0, %xmm2".
Fixes: 770c2fc7bb ("Add vector operations")
Backports commit 93bf9a42733321fb632bcb9eafd049ef0e3d9417 from qemu
The ARMv8 architecture defines that an AArch32 CPU starts
in SVC mode, unless EL2 is the highest available EL, in
which case it starts in Hyp mode. (In ARMv7 a CPU with EL2
but not EL3 was not a valid configuration, but we don't
specifically reject this if the user asks for one.)
Backports commit 060a65df056a5d6ca3a6a91e7bf150ca1fbccddf from qemu
Not only are the sve-related tb_flags fields unused when SVE is
disabled, but not all of the cpu registers are initialized properly
for computing same. This can corrupt other fields by ORing in -1,
which might result in QEMU crashing.
This bug was not present in 3.0, but this patch is cc'd to
stable because adf92eab90e3f5f34c285 where the bug was
introduced was marked for stable.
Backports commit e79b445d896deb61909be52b61b87c98a9ed96f7 from qemu
We emit a dummy variable in each .c file "to shut up OSX toolchain
warnings about empty .o files" (commit 252dc3105fc). Separate it from
the code preceding it (if any) with a blank line.
Backports commit 5f1450f5444b42cde4b1edc61ea5fdcd57404d3e from qemu
The generated qapi_event_send_FOO() take an Error ** argument. They
can't actually fail, because all they do with the argument is passing it
to functions that can't fail: the QObject output visitor, and the
@qmp_emit callback, which is either monitor_qapi_event_queue() or
event_test_emit().
Drop the argument, and pass &error_abort to the QObject output visitor
and @qmp_emit instead.
Backports commit 3ab72385b21d8d66df3f5fea42097ce264dc9d6b from qemu
build_params() returns '' instead of 'void' when there are no
parameters. Can't happen now, but the next commit will change that.
Backports commit bdd2d42b890b3a908fa3fbdc9661541e1b57eb15 from qemu
This was intentionally broken to make updating qemu as quick as possible
when it was woefully out of date, particularly because the interface of
qemu's TCG changed quite a bit, so this code would have needed to be
changed anyways.
Now that qemu is up to date for this variant of Unicorn, we can repair
this functionality and also--and I put massive emphasis on this, since
this wasn't done in the original Unicorn repo--*actually document what
the heck we're doing in this case*, so it's not a pain to change in the
future if we actually need to do that. It makes it much, much, simpler
for people not involved with qemu to understand what is going on in this
case.
