hw/vesa: Switch trap handling to use MMIO handler

To be able to use the VESA device with the new generic I/O trap handler,
we need to use the different MMIO handler callback routine.

Replace the ex

hw/vesa: Switch trap handling to use MMIO handler

To be able to use the VESA device with the new generic I/O trap handler,
we need to use the different MMIO handler callback routine.

Replace the existing dummy in and out handlers with a joint dummy
MMIO handler, and register this using the new registration function.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Alexandru Elisei <alexandru.elisei@arm.com>
Link: https://lore.kernel.org/r/20210315153350.19988-13-andre.przywara@arm.com
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

pci: Implement callbacks for toggling BAR emulation

Implement callbacks for activating and deactivating emulation for a BAR
region. This is in preparation for allowing a guest operating system to
en

pci: Implement callbacks for toggling BAR emulation

Implement callbacks for activating and deactivating emulation for a BAR
region. This is in preparation for allowing a guest operating system to
enable and disable access to I/O or memory space, or to reassign the
BARs.

The emulated vesa device framebuffer isn't designed to allow stopping and
restarting at arbitrary points in the guest execution. Furthermore, on x86,
the kernel will not change the BAR addresses, which on bare metal are
programmed by the firmware, so take the easy way out and refuse to
activate/deactivate emulation for the BAR regions. We also take this
opportunity to make the vesa emulation code more consistent by moving all
static variable definitions in one place, at the top of the file.

Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Link: https://lore.kernel.org/r/1589470709-4104-9-git-send-email-alexandru.elisei@arm.com
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

Don't allow more than one framebuffers

A vesa device is used by the SDL, GTK or VNC framebuffers. Don't allow the
user to specify more than one of these options because kvmtool will create
identical

Don't allow more than one framebuffers

A vesa device is used by the SDL, GTK or VNC framebuffers. Don't allow the
user to specify more than one of these options because kvmtool will create
identical vesa devices and bad things will happen:

$ ./lkvm run -c2 -m2048 -k bzImage --sdl --gtk
# lkvm run -k bzImage -m 2048 -c 2 --name guest-10159
Error: device region [d0000000-d012bfff] would overlap device region [d0000000-d012bfff]
*** Error in `./lkvm': free(): invalid pointer: 0x00007fad78002e40 ***
*** Error in `./lkvm': free(): invalid pointer: 0x00007fad78002e40 ***
*** Error in `./lkvm': free(): invalid pointer: 0x00007fad78002e40 ***
======= Backtrace: =========
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7fae0ed447e5]
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6/lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x7fae0ed4d37a]
(+0x777e5)[0x7fae0ed447e5]
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7fae0ed447e5]
/lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x7fae0ed4d37a]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7fae0ed5153c]
*** Error in `./lkvm': free(): invalid pointer: 0x00007fad78002e40 ***
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_string_free+0x3b)[0x7fae0f814dab]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_string_free+0x3b)[0x7fae0f814dab]
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0(+0x21121c)[0x7fae1023321c]
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0(+0x21121c)[0x7fae1023321c]
======= Backtrace: =========
Aborted (core dumped)

The vesa device is explicitly created during the initialization phase of
the above framebuffers. Also remove the superfluous check for their
existence.

Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Link: https://lore.kernel.org/r/1589470709-4104-8-git-send-email-alexandru.elisei@arm.com
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

hw/vesa: Set the size for BAR 0

Implemented BARs have an non-zero address and a size. Let's set the size
for BAR 0.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Alexandru Eli

hw/vesa: Set the size for BAR 0

Implemented BARs have an non-zero address and a size. Let's set the size
for BAR 0.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

hw/vesa: Don't ignore fatal errors

Failling an mmap call or creating a memslot means that device emulation
will not work, don't ignore it.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signe

hw/vesa: Don't ignore fatal errors

Failling an mmap call or creating a memslot means that device emulation
will not work, don't ignore it.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

Don't ignore errors registering a device, ioport or mmio emulation

An error returned by device__register, kvm__register_mmio and
ioport__register means that the device will
not be emulated properly.

Don't ignore errors registering a device, ioport or mmio emulation

An error returned by device__register, kvm__register_mmio and
ioport__register means that the device will
not be emulated properly. Annotate the functions with __must_check, so we
get a compiler warning when this error is ignored.

And fix several instances where the caller returns 0 even if the function
failed.

Also make sure the ioport emulation code uses ioport_remove consistently.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

virtio: Don't ignore initialization failures

Don't ignore an error in the bus specific initialization function in
virtio_init; don't ignore the result of virtio_init; and don't return 0
in virtio_bl

virtio: Don't ignore initialization failures

Don't ignore an error in the bus specific initialization function in
virtio_init; don't ignore the result of virtio_init; and don't return 0
in virtio_blk__init and virtio_scsi__init when we encounter an error.
Hopefully this will save some developer's time debugging faulty virtio
devices in a guest.

To take advantage of the cleanup function virtio_blk__exit, move appending
the new device to the list before the call to virtio_init. Change
virtio_net__exit to free all allocated net_dev devices on exit, and
matching what virtio_blk__exit does.

To safeguard against this in the future, virtio_init has been annoted
with the compiler attribute warn_unused_result.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

pci: Fix ioport allocation size

The PCI Local Bus Specification, Rev. 3.0,
Section 6.2.5.1. "Address Maps" states:
"Devices that map control functions into I/O Space must not consume more
than 256 b

pci: Fix ioport allocation size

The PCI Local Bus Specification, Rev. 3.0,
Section 6.2.5.1. "Address Maps" states:
"Devices that map control functions into I/O Space must not consume more
than 256 bytes per I/O Base Address register."

Yet all the PCI devices allocate IO ports of IOPORT_SIZE (= 1024 bytes).

Fix this by having PCI devices use 256 bytes ports for IO BARs.

There is no hard requirement on the size of the memory region described
by memory BARs. Since BAR 1 is supposed to offer the same functionality as
IO ports, let's make its size match BAR 0.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Julien Thierry <julien.thierry@arm.com>
[Added rationale for changing BAR1 size to PCI_IO_SIZE]
Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

ioport: pci: Move port allocations to PCI devices

The dynamic ioport allocation with IOPORT_EMPTY is currently only used
by PCI devices. Other devices use fixed ports for which they request
registra

ioport: pci: Move port allocations to PCI devices

The dynamic ioport allocation with IOPORT_EMPTY is currently only used
by PCI devices. Other devices use fixed ports for which they request
registration to the ioport API.

PCI ports need to be in the PCI IO space and there is no reason ioport
API should know a PCI port is being allocated and needs to be placed in
PCI IO space. This currently just happens to be the case.

Move the responsability of dynamic allocation of ioports from the ioport
API to PCI.

In the future, if other types of devices also need dynamic ioport
allocation, they'll have to figure out the range of ports they are
allowed to use.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Julien Thierry <julien.thierry@arm.com>
[Renamed functions for clarity]
Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

Check that a PCI device's memory size is power of two

According to the PCI local bus specification [1], a device's memory size
must be a power of two. This is also implicit in the mechanism that a C

Check that a PCI device's memory size is power of two

According to the PCI local bus specification [1], a device's memory size
must be a power of two. This is also implicit in the mechanism that a CPU
uses to get the memory size requirement for a PCI device.

The vesa device requests a memory size that isn't a power of two.
According to the same spec [1], a device is allowed to consume more memory
than it actually requires. As a result, the amount of memory that the vesa
device now reserves has been increased.

To prevent slip-ups in the future, a few BUILD_BUG_ON statements were added
in places where the memory size is known at compile time.

[1] PCI Local Bus Specification Revision 3.0, section 6.2.5.1

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

Extend memory bank API with memory types

Introduce memory types RAM and DEVICE, along with a way for subsystems to
query the global memory banks. This is required by VFIO, which will need
to pin and

Extend memory bank API with memory types

Introduce memory types RAM and DEVICE, along with a way for subsystems to
query the global memory banks. This is required by VFIO, which will need
to pin and map guest RAM so that assigned devices can safely do DMA to it.
Depending on the architecture, the physical map is made of either one or
two RAM regions. In addition, this new memory types API paves the way to
reserved memory regions introduced in a subsequent patch.

For the moment we put vesa and ivshmem memory into the DEVICE category, so
they don't have to be pinned. This means that physical devices assigned
with VFIO won't be able to DMA to the vesa frame buffer or ivshmem. In
order to do that, simply changing the type to "RAM" would work. But to
keep the types consistent, it would be better to introduce flags such as
KVM_MEM_TYPE_DMA that would complement both RAM and DEVICE type. We could
then reuse the API for generating firmware information (that is, for x86
bios; DT supports reserved-memory description).

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

show more ...

kvmtool: virtio: pass trapped vcpu to IO accessors

The recent introduction of bi-endianness on arm/arm64 had the
odd effect of breaking virtio-pci support on these platforms, as the
device endian fi

kvmtool: virtio: pass trapped vcpu to IO accessors

The recent introduction of bi-endianness on arm/arm64 had the
odd effect of breaking virtio-pci support on these platforms, as the
device endian field defaults to being VIRTIO_ENDIAN_HOST, which
is the wrong thing to have on a bi-endian capable architecture.

The fix is to check for the endianness on the ioport path the
same way we do it for mmio, which implies passing the vcpu all
the way down. Patch is a bit ugly, but aligns MMIO and ioport nicely.

Tested on arm64 and x86.

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

show more ...

kvm tools: irq: move irq line allocation into device registration

For the MMIO and PCI buses, drivers typically allocate an IRQ line for
their device before registering the device with the device tr

kvm tools: irq: move irq line allocation into device registration

For the MMIO and PCI buses, drivers typically allocate an IRQ line for
their device before registering the device with the device tree for the
relevant bus.

This patch moves the IRQ allocation into the bus code, which is then
called directly by the device tree when a new device is registered.
IOPORT devices, however, tend to use hardcoded IRQs for legacy reasons,
so they are still required to deal with their interrupts (which also
require remapping for non-x86 architectures).

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

show more ...

kvm tools: irq: rename irq__register_device to irq__alloc_line

Since irq__register_device no longer registers a device with anything,
rename it to irq__alloc_line, which better describes what is act

kvm tools: irq: rename irq__register_device to irq__alloc_line

Since irq__register_device no longer registers a device with anything,
rename it to irq__alloc_line, which better describes what is actually
going on.

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

show more ...

kvm tools: irq: remove remaining parameters to irq__register_device

With the removal of the x86 irq rbtree, the only parameter used by
irq__register_device is actually used to return the new line.

kvm tools: irq: remove remaining parameters to irq__register_device

With the removal of the x86 irq rbtree, the only parameter used by
irq__register_device is actually used to return the new line.

This patch removes all of the parameters from irq__register_device and
returns the allocated line directly.

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

show more ...

kvm tools: irq: remove pin parameter from irq__register_device

In preparation for moving the irq allocation into generic code, remove
the pin parameter from irq__register_device and temporarily plac

kvm tools: irq: remove pin parameter from irq__register_device

In preparation for moving the irq allocation into generic code, remove
the pin parameter from irq__register_device and temporarily place the
onus on the emulation driver to allocate the pin (which is always 1 and
only used on PCI anyway).

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

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: add generic device registration mechanism

PCI devices are currently registered into the pci_devices array via the
pci__register function, which can then be indexed later by architecture
c

kvm tools: add generic device registration mechanism

PCI devices are currently registered into the pci_devices array via the
pci__register function, which can then be indexed later by architecture
code to construct device tree nodes. For MMIO devices, there is no such
utility.

Rather than invent a similar mechanism for MMIO, this patch creates a
global device registration mechanism, which allows the device type to be
specified when registered or indexing a device. Current users of the pci
registration code are migrated to the new infrastructure and virtio MMIO
devices are registered at init time.

As part of the device registration, allocation of the device number is
moved out of irq__register_device and performed when adding the device
header to the relevant bus tree, allowing us to maintain separate device
numberspaces for each bus.

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

show more ...

kvm tools: remove global kvm object

This was ugly, and now we get rid of it.

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

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 kvm_cpus into struct kvm

There's no reason the array of guest specific vcpus is global. Move it into
struct kvm.

Also split up arch specific vcpu init from the generic code and call

kvm tools: move kvm_cpus into struct kvm

There's no reason the array of guest specific vcpus is global. Move it into
struct kvm.

Also split up arch specific vcpu init from the generic code and call it from
the kvm_cpu initializer.

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

show more ...

kvm tools: Fixes for ioport module

Fixes include:
- Error handling
- Cleanup
- Standard init/uninit

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

kvm tools: Fixes for UI modules

Fixes include:
- Error handling
- Cleanup
- Standard init/uninit

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

kvm tools: Endian-sanitise pci.h and PCI device setup

vesa, pci-shmem and virtio-pci devices need to set up config space with
little-endian conversions (as config space is LE). The pci_config_addre

kvm tools: Endian-sanitise pci.h and PCI device setup

vesa, pci-shmem and virtio-pci devices need to set up config space with
little-endian conversions (as config space is LE). The pci_config_address
bitfield also needs to be reversed when building on BE systems.

Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: remove count in io emulation callbacks

'count' parameter in io emulation callbacks is useless, just remove it

Signed-off-by: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
Signed-off-by:

kvm tools: remove count in io emulation callbacks

'count' parameter in io emulation callbacks is useless, just remove it

Signed-off-by: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...