Martin Stein 1336b0a751 mmio: upper-bounds checks
The classes Genode::Mmio, Genode::Register_set, Genode::Attached_mmio, and
Platform::Device::Mmio now receive a template parameter 'size_t SIZE'. In each
type that derives from one of these classes, it is now statically checked that
the range of each Genode::Register::Register- and
Genode::Register_set::Register_array-deriving sub-type is within [0..SIZE).

That said, SIZE is the minimum size of the memory region provided to the above
mentioned Mmio classes in order to avoid page faults or memory corruption when
accessing the registers and register arrays declared inside.

Note, that the range end of a register array is not the end of the last item
but the end of integer access that is used for accessing the last bit in the
last item.

The constructors of Genode::Mmio, Genode::Attached_mmio, and
Platform::Device::Mmio now receive an argument 'Byte_range_ptr range' that is
expected to be the range of the backing memory region. In each type that derives
from on of these classes, it is now dynamically checked that 'range.num_bytes
>= SIZE', thereby implementing the above mention protection against page faults
and memory corruption.

The rest of the commit adapts the code throughout the Genode Labs repositories
regarding the changes. Note that for that code inside Core, the commits mostly
uses a simplified approach by constructing MMIO objects with range
[base..base+SIZE) and not with a mapping- or specification-related range size.
This should be fixed in the future.

Furthermore, there are types that derive from an MMIO class but don't declare
any registers or register arrays (especially with Platform::Device::Mmio). In
this case SIZE is set to 0. This way, the parameters must be actively corrected
by someone who later wants to add registers or register arrays, plus the places
can be easily found by grep'ing for Mmio<0>.

Fix #4081
2024-02-26 08:59:07 +01:00
..
2022-11-17 08:00:37 +01:00
2023-11-28 14:24:24 +01:00
2020-04-17 12:52:02 +02:00
2024-02-26 08:59:07 +01:00
2022-11-17 08:00:37 +01:00
2020-04-17 12:52:02 +02:00
2022-11-17 08:00:37 +01:00
2023-02-27 08:22:49 +01:00
2022-11-17 08:00:37 +01:00
2024-02-26 08:59:07 +01:00
2023-02-27 08:20:45 +01:00
2024-02-26 08:59:07 +01:00
2024-02-26 08:59:07 +01:00
2024-02-26 08:59:07 +01:00
2024-02-26 08:59:07 +01:00
2024-02-26 08:59:07 +01:00
2024-02-26 08:59:07 +01:00
2024-02-26 08:59:07 +01:00
2024-02-26 08:59:07 +01:00
2024-02-26 08:59:07 +01:00

The vmm component implements a virtual-machine monitor that is able to
drive Linux VMs on ARMv7 and ARMv8 using hardware-assisted virtualization.
It uses the VM session for ARM, currently provided by the base-hw kernel only.
It is limited to load Linux kernel binaries and an initram-filesystem only.

The VMM produces a flattened device-tree blob (DTB) to the Linux guest OS
that is derived from the configuration of the VMM.

The following configuration attributes are evaluated:

! <config kernel_rom="linux"
!         initrd_rom="initrd"
!         ram_size="512M"
!         cpu_count="1"
!         cpu_type="arm,cortex-a53"
!         gic_version="3"
!         bootargs="console=hvc0"/>

Configuration attributes explained in more detail:

:kernel_rom:
  This attribute is optional. It denotes the ROM, which is requested as kernel
  binary to be loaded. The default name requested will be "linux". Please note
  that the Linux kernel image shouldn't be gzipped, because the VMM does not
  deflate the image before loading.

:initrd_rom:
  This attribute is optional. It denotes the ROM, which is requested as initramfs
  resp. initrd to be loaded. If no name is given, no initramfs will be provided
  to the guest OS.

:ram_size:
  This attribute is mandatory. It defines the size of the VM's memory.

:cpu_count:
  This attribute is mandatory. It defines the available number of virtual CPUs
  for the VM. The virtual CPUs are getting assigned round-robin to the physical
  CPUs available to the VMM.

:cpu_type:
  This attribute's default value is "arm,cortex-a15". If your underlying hardware
  has a different one, you should use here the Linux-specific CPU compatible string
  for the actual CPU of your board.

:gic_version:
  This attribute's default value is "2". If your underlying hardware uses a
  different ARM Generic Interrupt Controller version, you should specify the
  actual version here. The only versions allowed are 2 and 3. Other interrupt
  controller models are not supported.

:bootargs:
  This attribute is mandatory. It defines the Linux kernel's cmdline. The default
  value is "console=ttyAMA0"


Virtio devices
--------------

In addition to the general configuration attributes, one can define several Virtio
devices per VM. This is done by configuration sub-nodes, like:

! <config ram_size="128M" cpu_count="1" ... >
!
!   <virtio_device name="hvc0" type="console"/>
!   ...
! </config>

For each virtio_device node the following attributes need to be set:

:name:
  A unique name denoting the device.

:type:
  The Virtio type of device. One can decide in between "console", "net", "gpu",
  "input", and "block". The "console" type gets mapped to a Genode Terminal
  session, "net" is mapped to a Nic session, "gpu" is mapped to a Gui session,
  "input" to the event part of the Gui session, and "block" to a Block session.

Additional devices
------------------

Apart from defined Virtio devices, as well as the defined CPUs and GIC version,
the VMM always assigns a PL011 UART device to the VM, which gets connected to
a Terminal session as backend. This Terminal session uses "earlycon" as
last label.