The core of the machine-type support is the new operations table,
kvm_ops_t. This acts as a standard C-style virtual table decoupling the
generic KVM core logic from target specific hardware emualtion. The
kvm_t VM instance now points to an ops table, which defines the
"personality" of the guest. A kvm_probe() factory function has been
added to initialize a kvm_t instance with the correct ops table for a
given machine type (eg, Switch 1).
The ops table's .mmio_read and .mmio_write function pointers are the
link between the armv8 CPU core and this new MMIO dispatcher. When a
physical memory access is determined to be MMIO, the VM will call the
appropriate function pointer, which in turn will use the MMIO dispatcher
to find and execute the correct device handler.
The initial implementation for the Switch 1 target
(targets/switch1/hardware/probe.cpp) is a stub. The bootstrapping
logic will be added in subsequent patches.
Signed-off-by: Ronald Caesar <github43132@proton.me>
Introduce a software-based page table walker for the arm64 MMU
emulation. This is foundational component for handling GVA-GPA
translations when a request missses the (future) software TLB.
For now, it handles only Page descriptors and does not yet support Block
descriptors or permission checks. These will be added in subsequent
patches.
Signed-off-by: Ronald Caesar <github43132@proton.me>
Pound's asserts were broken from the very beginning and I've just
realized this. Fixing it is not my problem.
Signed-off-by: Ronald Caesar <github43132@proton.me>
The term "memory" is really ambiguous in the context of an emulator,
especially since the MMU is being developed. It can refer to host memory, or
guest memory, or both.
Signed-off-by: Ronald Caesar <github43132@proton.me>
The term "aarch64" is the formal name for Armv8-A architecture. However,
I found that the establish convention across the wider open source
ecosystem is to use the short name "arm64".
Signed-off-by: Ronald Caesar <github43132@proton.me>
