Add virtio-transport option and deprecate force-pci and virtio-legacy.

This is a follow-up patch for [0] which proposed the --force-pci option
for riscv. As per the discussion it was concluded to ad

Add virtio-transport option and deprecate force-pci and virtio-legacy.

This is a follow-up patch for [0] which proposed the --force-pci option
for riscv. As per the discussion it was concluded to add virtio-tranport
option taking in four options (pci, pci-legacy, mmio, mmio-legacy).

With this change force-pci and virtio-legacy are both deprecated and
arm's default transport changes from MMIO to PCI as agreed in [0].
This is also true for riscv.

Nothing changes for other architectures.

[0]: https://lore.kernel.org/all/20230118172007.408667-1-rkanwal@rivosinc.com/

Signed-off-by: Rajnesh Kanwal <rkanwal@rivosinc.com>
Link: https://lore.kernel.org/r/20230320143344.404307-1-rkanwal@rivosinc.com
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

virtio: Add support for modern virtio-pci

Add support for modern virtio-pci implementation (based on the 1.0 virtio
spec). We add a new transport, alongside MMIO and PCI-legacy. This is now
the defa

virtio: Add support for modern virtio-pci

Add support for modern virtio-pci implementation (based on the 1.0 virtio
spec). We add a new transport, alongside MMIO and PCI-legacy. This is now
the default when selecting PCI, but users can still select the legacy
transport for all virtio devices by passing "--virtio-legacy" on the
command-line.

The main change in modern PCI is the way we address virtqueues, using
64-bit values instead of PFNs. To keep the queue configuration atomic the
device also gets a "queue enable" register. Configuration is also made
extensible by more feature bits and PCI capabilities. Scalability is
improved as well, as devices can have notification registers for each
virtqueue on separate pages. However this implementation keeps a single
notification register.

Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Link: https://lore.kernel.org/r/20220701142434.75170-9-jean-philippe.brucker@arm.com
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

arm64: Allow the user to specify the RAM base address

Allow the user to specify the RAM base address by using -m/--mem size@addr
command line argument. The base address must be above 2GB, as to not

arm64: Allow the user to specify the RAM base address

Allow the user to specify the RAM base address by using -m/--mem size@addr
command line argument. The base address must be above 2GB, as to not
overlap with the MMIO I/O region.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
Reviewed-and-Tested-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20220616134828.129006-13-alexandru.elisei@arm.com
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

builtin-run: Always use RAM size in bytes

The user can specify the virtual machine memory size in MB, which is saved
in cfg->ram_size. kvmtool validates it against the host memory size,
converted fr

builtin-run: Always use RAM size in bytes

The user can specify the virtual machine memory size in MB, which is saved
in cfg->ram_size. kvmtool validates it against the host memory size,
converted from bytes to MB. ram_size is then converted to bytes, and this
is how it is used throughout the rest of kvmtool.

To avoid any confusion about the unit of measurement, especially once the
user is allowed to specify the unit of measurement, always use ram_size in
bytes.

Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-and-Tested-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20220616134828.129006-3-alexandru.elisei@arm.com
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

Make --no-pvtime command argument arm specific

The stolen time option is available only for aarch64 and is enabled by
default. Move the option that disables stolen time functionality in the
arch spe

Make --no-pvtime command argument arm specific

The stolen time option is available only for aarch64 and is enabled by
default. Move the option that disables stolen time functionality in the
arch specific path.

Signed-off-by: Sebastian Ene <sebastianene@google.com>
Link: https://lore.kernel.org/r/20220324154304.2572891-1-sebastianene@google.com
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

aarch64: Add stolen time support

This patch adds support for stolen time by sharing a memory region
with the guest which will be used by the hypervisor to store the stolen
time information. Reserve

aarch64: Add stolen time support

This patch adds support for stolen time by sharing a memory region
with the guest which will be used by the hypervisor to store the stolen
time information. Reserve a 64kb MMIO memory region after the RTC peripheral
to be used by pvtime. The exact format of the structure stored by the
hypervisor is described in the ARM DEN0057A document.

Reviewed-by: Alexandru Elisei <alexandru.elisei@arm.com>
Tested-by: Alexandru Elisei <alexandru.elisei@arm.com>
Signed-off-by: Sebastian Ene <sebastianene@google.com>
Link: https://lore.kernel.org/r/20220313161949.3565171-3-sebastianene@google.com
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

Add --nodefaults command line argument

kvmtool attempts to make it as easier as possible on the user to run a VM
by doing a few different things: it tries to create a rootfs filesystem in
a director

Add --nodefaults command line argument

kvmtool attempts to make it as easier as possible on the user to run a VM
by doing a few different things: it tries to create a rootfs filesystem in
a directory if not disk or initrd is set by the user, and it adds various
parameters to the kernel command line based on the VM configuration
options.

While this is generally very useful, today there isn't any way for the user
to prohibit this behaviour, even though there are situations where this
might not be desirable, like, for example: loading something which is not a
kernel (kvm-unit-tests comes to mind, which expects test parameters on the
kernel command line); the kernel has a built-in initramfs and there is no
need to generate the root filesystem, or it not possible; and what is
probably the most important use case, when the user is actively trying to
break things for testing purposes.

Add a --nodefaults command line argument which disables everything that
cannot be disabled via another command line switch. The purpose of this
knob is not to disable the default options for arguments that can be set
via the kvmtool command line, but rather to inhibit behaviour that cannot
be disabled otherwise.

Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
Link: https://lore.kernel.org/r/20210923144505.60776-8-alexandru.elisei@arm.com
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

Use kvm->nr_disks instead of kvm->cfg.image_count

A user can specify multiple disk images using the --disk/-d argument. The
callback for the argument ends up in
disk/core.c::calling disk_img_name_pa

Use kvm->nr_disks instead of kvm->cfg.image_count

A user can specify multiple disk images using the --disk/-d argument. The
callback for the argument ends up in
disk/core.c::calling disk_img_name_parser(), which increments
kvm->cfg.image_count for each disk image.

Immediately after parsing the arguments in kvm_cmd_run_init(),
kvm->nr_disks is set to kvm->cfg.image_count, effectively making
kvm->nr_disks an alias for kvm->cfg.image_count, as image_count is never
changed afterward.

Later on, the core disk code uses kvm->cfg.image_count when opening all the
disk images, but kvm->nr_disks when closing them, which is inconsistent,
but technically correct since they represent the same thing and have the
same value.

Let's remove all this confusing usage and use only kvm->nr_disks to
represent the number of disk images specified by the user.

While this technically means that kvmtool now supports up to INT_MAX disk
images, in practice this is limited by MAX_DISK_IMAGES, which is equal to
four. Which means there are no functional changes.

Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
Link: https://lore.kernel.org/r/20210923144505.60776-6-alexandru.elisei@arm.com
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

virtio: add support for vsock

The "run" command accepts a new option (--vsock <cid>) which specify the
guest CID. For instance:

$ lkvm run --kernel ./bzImage --disk test --vsock 3

One can easily

virtio: add support for vsock

The "run" command accepts a new option (--vsock <cid>) which specify the
guest CID. For instance:

$ lkvm run --kernel ./bzImage --disk test --vsock 3

One can easily test by: https://github.com/stefanha/nc-vsock.

In the guest:

# modprobe vsock
# nc-vsock -l 1234

In the host:

# modprobe vhost_vsock
# nc-vsock 3 1234

This patch comes from the early submission of G. Campana. On this basis,
I fixed the compilation errors and runtime crashes. Thanks for the work
done by G. Campana.
https://patchwork.kernel.org/patch/9542313/

Signed-off-by: G. Campana <gcampana+kvm@quarkslab.com>
Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Link: https://lore.kernel.org/r/20200915094402.107988-1-tianjia.zhang@linux.alibaba.com
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

Add emulation for CFI compatible flash memory

The EDK II UEFI firmware implementation requires some storage for the EFI
variables, which is typically some flash storage.
Since this is already suppor

Add emulation for CFI compatible flash memory

The EDK II UEFI firmware implementation requires some storage for the EFI
variables, which is typically some flash storage.
Since this is already supported on the EDK II side, we add a CFI flash
emulation to kvmtool.
This is backed by a file, specified via the --flash or -F command line
option. Any flash writes done by the guest will immediately be reflected
into this file (kvmtool mmap's the file).
The flash will be limited to the nearest power-of-2 size, so only the
first 2 MB of a 3 MB file will be used.

This implements a CFI flash using the "Intel/Sharp extended command
set", as specified in:
- JEDEC JESD68.01
- JEDEC JEP137B
- Intel Application Note 646
Some gaps in those specs have been filled by looking at real devices and
other implementations (QEMU, Linux kernel driver).

At the moment this relies on DT to advertise the base address of the
flash memory (mapped into the MMIO address space) and is only enabled
for ARM/ARM64. The emulation itself is architecture agnostic, though.

This is one missing piece toward a working UEFI boot with kvmtool on
ARM guests, the other is to provide writable PCI BARs, which is WIP.

Tested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Raphael Gault <raphael.gault@arm.com>
[Andre: rewriting and fixing]
Signed-off-by: Andre Przywra <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

Add PCI device passthrough using VFIO

Assigning devices using VFIO allows the guest to have direct access to the
device, whilst filtering accesses to sensitive areas by trapping config
space accesse

Add PCI device passthrough using VFIO

Assigning devices using VFIO allows the guest to have direct access to the
device, whilst filtering accesses to sensitive areas by trapping config
space accesses and mapping DMA with an IOMMU.

This patch adds a new option to lkvm run: --vfio-pci=<BDF>. Before
assigning a device to a VM, some preparation is required. As described in
Linux Documentation/vfio.txt, the device driver needs to be changed to
vfio-pci:

$ dev=0000:00:00.0

$ echo $dev > /sys/bus/pci/devices/$dev/driver/unbind
$ echo vfio-pci > /sys/bus/pci/devices/$dev/driver_override
$ echo $dev > /sys/bus/pci/drivers_probe

Adding --vfio-pci=$dev to lkvm-run will pass the device to the guest.
Multiple devices can be passed to the guest by adding more --vfio-pci
parameters.

This patch only implements PCI with INTx. MSI-X routing will be added in a
subsequent patch, and at some point we might add support for passing
platform devices to guests.

Reviewed-by: Punit Agrawal <punit.agrawal@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

kvm tools: Initial GTK+ 3.0 UI

It's barely usable but it isn't getting any better sitting alone in a
private git branch.

You can start a new VM with the GTK UI like this:

./vm run --gtk

It's ro

kvm tools: Initial GTK+ 3.0 UI

It's barely usable but it isn't getting any better sitting alone in a
private git branch.

You can start a new VM with the GTK UI like this:

./vm run --gtk

It's rough around the edges:

- Red and blue color channels are inverted.
- Some keys do not work.
- Mouse does not work.
- GTK assertion failure pops up on shutdown.

but I'm sure there's someone out there that's just dying to improve the
user experience.

Cc: Asias He <asias.hejun@gmail.com>
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: allow arch's to provide their own command-line options

Currently, only x86 has architecture command-line options (for setting
the BIOS video mode) however this is likely to become more co

kvm tools: allow arch's to provide their own command-line options

Currently, only x86 has architecture command-line options (for setting
the BIOS video mode) however this is likely to become more common in the
future.

This patch adds some simple macros and a struct definition to allow
architectures to augment the command-line options with private
definitions. The BIOS video mode option (--vidmode) is also migrated to
the new framework.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: kernel load/firmware cleanup

Sort out the config initialization order so that configuration is fully initialized
before init functions start running, and move the firmware initialization

kvm tools: kernel load/firmware cleanup

Sort out the config initialization order so that configuration is fully initialized
before init functions start running, and move the firmware initialization code into
kvm.c.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: ui improvements

Move the vesa initialization logic into sdl__init() and vnc__init(), builtin-run
shouldn't have to know about the conditions for initializing vesa on it's own.

Signed-off

kvm tools: ui improvements

Move the vesa initialization logic into sdl__init() and vnc__init(), builtin-run
shouldn't have to know about the conditions for initializing vesa on it's own.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: move nrcpus into struct kvm_config

This no longer has to be a global since we now have kvm_config.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penbe

kvm tools: move nrcpus into struct kvm_config

This no longer has to be a global since we now have kvm_config.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: disk image related cleanup

Move io debug delay into kvm_config, the parser out of builtin-run into the disk code
and make the init/exit functions match the rest of the code in style.

Sig

kvm tools: disk image related cleanup

Move io debug delay into kvm_config, the parser out of builtin-run into the disk code
and make the init/exit functions match the rest of the code in style.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: move active_console into struct kvm_config

This config option was 'extern'ed between different objects. Clean it up
and move it into struct kvm_config.

Signed-off-by: Sasha Levin <levins

kvm tools: move active_console into struct kvm_config

This config option was 'extern'ed between different objects. Clean it up
and move it into struct kvm_config.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: move mmio_debug into struct kvm_config

This config option was 'extern'ed between different objects. Clean it up
and move it into struct kvm_config.

Signed-off-by: Sasha Levin <levinsasha

kvm tools: move mmio_debug into struct kvm_config

This config option was 'extern'ed between different objects. Clean it up
and move it into struct kvm_config.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: move ioport_debug into struct kvm_config

This config option was 'extern'ed between different objects. Clean it up
and move it into struct kvm_config.

Signed-off-by: Sasha Levin <levinsas

kvm tools: move ioport_debug into struct kvm_config

This config option was 'extern'ed between different objects. Clean it up
and move it into struct kvm_config.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: introduce kvm_config to store instance-specific config options

Move all the configurable options from global static variables to a self-contained
structure.

Signed-off-by: Sasha Levin <l

kvm tools: introduce kvm_config to store instance-specific config options

Move all the configurable options from global static variables to a self-contained
structure.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...