Support target CPUs having a page size which isn't knownn
at compile time. To use this, the CPU implementation should:
* define TARGET_PAGE_BITS_VARY
* not define TARGET_PAGE_BITS
* define TARGET_PAGE_BITS_MIN to the smallest value it
might possibly want for TARGET_PAGE_BITS
* call set_preferred_target_page_bits() in its realize
function to indicate the actual preferred target page
size for the CPU (and report any error from it)
In CONFIG_USER_ONLY, the CPU implementation should continue
to define TARGET_PAGE_BITS appropriately for the guest
OS page size.
Machines which want to take advantage of having the page
size something larger than TARGET_PAGE_BITS_MIN must
set the MachineClass minimum_page_bits field to a value
which they guarantee will be no greater than the preferred
page size for any CPU they create.
Note that changing the target page size by setting
minimum_page_bits is a migration compatibility break
for that machine.
For debugging purposes, attempts to use TARGET_PAGE_SIZE
before it has been finally confirmed will assert.
Backports commit 20bccb82ff3ea09bcb7c4ee226d3160cab15f7da from qemu
Remove L1 page mapping table properties computing
statically using macros which is dependent on
TARGET_PAGE_BITS. Drop macros V_L1_SIZE, V_L1_SHIFT,
V_L1_BITS macros and replace with variables which are
computed at early stage of VM boot.
Removing dependency can help to make TARGET_PAGE_BITS
dynamic.
Backports commit 66ec9f49399f0a9fa13ee77c472caba0de2773fc from qemu
this is the first step in reducing the brk heap fragmentation
created by the map->nodes memory allocation. Since the introduction
of RCU the freeing of the PhysPageMaps is delayed so that sometimes
several hundred are allocated at the same time.
Even worse the memory for map->nodes is allocated and shortly
afterwards reallocated. Since the number of nodes it grows
to in the end is the same for all PhysPageMaps remember this value
and at least avoid the reallocation.
The large number of simultaneous allocations (about 450 x 70kB in
my configuration) has to be addressed later.
Backports commit 101420b886eec36990419bc9ed5b503622af8a0d from qemu
This is already useful on Windows in order to remove tls.h, because
accesses to current_cpu are done from a different thread on that
platform. It will be used on POSIX platforms as soon TCG stops using
signals to interrupt the execution of translated code.
Backports commit 9373e63297c43752f9cf085feb7f5aed57d959f8 from qemu
Writing / reading to model specific registers should be as easy as
calling a function, it's a bit stupid to write shell code and run them
just to write/read to a MSR, and even worse, you need more than just a
shellcode to read...
So, add a special register ID called UC_X86_REG_MSR, which should be
passed to uc_reg_write()/uc_reg_read() as the register ID, and then a
data structure which is uc_x86_msr (12 bytes), as the value (always), where:
Byte Value Size
0 MSR ID 4
4 MSR val 8
* reg_read and reg_write now work with registers W0 through W30 in Aarch64 emulaton
* Added a regress test for the ARM64 reg_read and reg_write on 32-bit registers (W0-W30)
Added a new macro in uc_priv.h (WRITE_DWORD_TO_QWORD), in order to write to the lower 32 bits of a 64 bit value without overwriting the whole value when using reg_write
* Fixed WRITE_DWORD macro
reg_write would zero out the high order bits when writing to 32 bit registers
e.g. uc.reg_write(UC_X86_REG_EAX, 0) would also set register RAX to zero
Support for Cortex-M ARM CPU already exists in Qemu. This patch just
exposes a "cortex-m3" CPU.
"uc_open(UC_ARCH_ARM, UC_MODE_THUMB | UC_MODE_MCLASS, &uc);"
Instantiates a CPU with this feature on.
Signed-off-by: Lucian Cojocar <lucian@cojocar.com>
ARM and probably the rest of the arches have significant memory leaks as
they have no release interface.
Additionally, DrMemory does not have 64-bit support and thus I can't
test the 64-bit version under Windows. Under Linux valgrind supports
both 32-bit and 64-bit but there are different macros and code for Linux
and Windows.
