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 ...

vfio/pci: Align MSIX Table and PBA size to guest maximum page size

When allocating MMIO space for the MSI-X table, kvmtool rounds the
allocation to the host's page size to make it as easy as possibl

vfio/pci: Align MSIX Table and PBA size to guest maximum page size

When allocating MMIO space for the MSI-X table, kvmtool rounds the
allocation to the host's page size to make it as easy as possible for the
guest to map the table to a page, if it wants to (and doesn't do BAR
reassignment, like the x86 architecture for example). However, the host's
page size can differ from the guest's on architectures which support
multiple page sizes. For example, arm64 supports three different page size,
and it is possible for the host to be using 4k pages, while the guest is
using 64k pages.

To make sure the allocation is always aligned to a guest's page size, round
it up to the maximum architectural page size. Do the same for the pending
bit array if it lives in its own BAR.

Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Link: https://lore.kernel.org/r/20211012132510.42134-8-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 ...

ioeventfd: Don't register on the PIO bus if the arch doesn't support it

virtio/pci.c registers a notification ioeventfd on both PIO and MMIO
buses. But architectures other than x86 cannot differenti

ioeventfd: Don't register on the PIO bus if the arch doesn't support it

virtio/pci.c registers a notification ioeventfd on both PIO and MMIO
buses. But architectures other than x86 cannot differentiate MMIO from
PIO traps, and the kernel always calls kvm_io_bus_read/write with
KVM_MMIO_BUS as argument.

As a result kvmtool's ioeventfd isn't used with virtio PCI, because the
kernel can't find it and all accesses to the doorbell return to
userspace. To fix it, don't set the PIO flag if the architecture doesn't
support it.

Fixes: a508ea95f954 ("virtio/pci: Use port I/O for configuration registers by default")
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

kvm tools: Provide per arch macro to specify type for KVM_CREATE_VM

This is is usually 0 for most archs. On mips we have two types.
TE (type 0) and MIPS-VZ (type 1). Default to 1 on mips.

Signed-of

kvm tools: Provide per arch macro to specify type for KVM_CREATE_VM

This is is usually 0 for most archs. On mips we have two types.
TE (type 0) and MIPS-VZ (type 1). Default to 1 on mips.

Signed-off-by: Andreas Herrmann <andreas.herrmann@caviumnetworks.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: ARM: allow default virtio transport to be passed on cmdline

This patch changes VIRTIO_DEFAULT_TRANS to take a struct kvm parameter,
allowing architectures to choose the default transport

kvm tools: ARM: allow default virtio transport to be passed on cmdline

This patch changes VIRTIO_DEFAULT_TRANS to take a struct kvm parameter,
allowing architectures to choose the default transport dynamically.

For ARM, this is driven by an arch-specific cmdline option.

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

show more ...

kvm tools: irq: make irq__alloc_line generic

All architectures are now doing the same thing for irq__alloc_line:

1. Initialise a global counter to some fixed offset
2. Return the current value

kvm tools: irq: make irq__alloc_line generic

All architectures are now doing the same thing for irq__alloc_line:

1. Initialise a global counter to some fixed offset
2. Return the current value of the counter and increment it

This is better off in core code, with each architecture specifying the
initial offset, which is specific to the interrupt controller being used
by the guest.

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

show more ...

kvm tools: pci: register 24-bit configuration space below MMIO region

Rather than performing all config accesses via ioports, map in a 24-bit
memory-mapped configuration space directly below the PCI

kvm tools: pci: register 24-bit configuration space below MMIO region

Rather than performing all config accesses via ioports, map in a 24-bit
memory-mapped configuration space directly below the PCI MMIO region.

This will allow architectures to support PCI without having to support
legacy ioports in the guest kernel. Instead, kvm tool can forward the
config accesses directly to the relevant ioport config callbacks.

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

show more ...

kvm tools: allow ioports to be offset from 0

Architectures without a legacy ioport may wish to emulate one, but not
at address 0x0.

This patch introduces KVM_IOPORT_AREA, which each architecture de

kvm tools: allow ioports to be offset from 0

Architectures without a legacy ioport may wish to emulate one, but not
at address 0x0.

This patch introduces KVM_IOPORT_AREA, which each architecture defines
to be the start of the ioport region (i.e. where port addresses are
offset from).

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

show more ...

kvm tools: allow arch to specify default virtio transport

Some architectures may provide only a restricted PCI implementation and
therefore prefer MMIO as the transport for virtio devices.

This pat

kvm tools: allow arch to specify default virtio transport

Some architectures may provide only a restricted PCI implementation and
therefore prefer MMIO as the transport for virtio devices.

This patch allows the arch backend to specify the default virtio
transport. Some devices (e.g. net) allow the transport to be overriden
by the user and are left alone by this change.

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

show more ...

kvm tools: make _FDT macro usable by other architectures

The _FDT macro is useful when generating device trees for a guest, so
make it available to other architectures.

Signed-off-by: Will Deacon <

kvm tools: make _FDT macro usable by other architectures

The _FDT macro is useful when generating device trees for a guest, so
make it available to other architectures.

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

show more ...

kvm tools: split struct kvm into arch specific part

Move all the non-arch specific members into a generic struct, and the arch specific
members into a arch specific kvm_arch. This prevents code dupl

kvm tools: split struct kvm into arch specific part

Move all the non-arch specific members into a generic struct, and the arch specific
members into a arch specific kvm_arch. This prevents code duplication across different
archs.

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

show more ...

kvm tools: Remember page size as kvm->ram_pagesize

On some powerpc platforms we need to make sure we only advertise page
sizes to the guest which are <= the size of the pages backing guest RAM.

So

kvm tools: Remember page size as kvm->ram_pagesize

On some powerpc platforms we need to make sure we only advertise page
sizes to the guest which are <= the size of the pages backing guest RAM.

So have mmap_hugetblfs() save the hugetblfs page size for us, and also
teach mmap_anon_or_hugetblfs() to set the page size for anonymous mmap.

Acked-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Define KVM_VIRTIO_MMIO_AREA for powerpc

Commit 82ea06e "Introduce KVM_VIRTIO_MMIO_AREA" did just that, but only
for x86. Causing the following commit 5c301a3 "Add virtio-mmio support"
to

kvm tools: Define KVM_VIRTIO_MMIO_AREA for powerpc

Commit 82ea06e "Introduce KVM_VIRTIO_MMIO_AREA" did just that, but only
for x86. Causing the following commit 5c301a3 "Add virtio-mmio support"
to break the build for powerpc.

We follow what x86 did and place it 16MB past the PCI area, I have no
idea if that is actually a good idea, or whether it works at all.

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tool: Make kvm structure to carry name copy

If default guest name is used (which is the default
case) the kvm might end up carrying the pointer to
a name which is allocated on stack.

kvm_cmd_ru

kvm tool: Make kvm structure to carry name copy

If default guest name is used (which is the default
case) the kvm might end up carrying the pointer to
a name which is allocated on stack.

kvm_cmd_run_init
(on stack) default_name
kvm__init(..., default_name)
kvm->name = default_name

So make it to carry a copy of name.

Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Add PPC64 PCI Host Bridge

This provides the PCI bridge, definitions for the address layout of the windows
and wires in IRQs. Once PCI devices are all registered, they are enumerated and

kvm tools: Add PPC64 PCI Host Bridge

This provides the PCI bridge, definitions for the address layout of the windows
and wires in IRQs. Once PCI devices are all registered, they are enumerated and
DT nodes generated for each.

Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Add PPC64 XICS interrupt controller support

This patch adds XICS emulation code (heavily borrowed from QEMU), and wires
this into kvm_cpu__irq() to fire a CPU IRQ via KVM. A device tree

kvm tools: Add PPC64 XICS interrupt controller support

This patch adds XICS emulation code (heavily borrowed from QEMU), and wires
this into kvm_cpu__irq() to fire a CPU IRQ via KVM. A device tree entry is
also added. IPIs work, xics_alloc_irqnum() is added to allocate an external
IRQ (which will later be used by the PHB PCI code) and finally, kvm__irq_line()
can be called to raise an IRQ on XICS.

Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Generate SPAPR PPC64 guest device tree

The generated DT is the bare minimum structure required for SPAPR (on which
subsequent patches for VIO, XICS, PCI etc. will build); root node, cpus,

kvm tools: Generate SPAPR PPC64 guest device tree

The generated DT is the bare minimum structure required for SPAPR (on which
subsequent patches for VIO, XICS, PCI etc. will build); root node, cpus, memory.

The DT contains CPU-specific configuration; a very simple 'cpu info' mechanism
is added to recognise/differentiate DT entries for POWER7 and PPC970 host CPUs.
Future support of more CPUs is possible.

libfdt is included from scripts/dtc/libfdt.

Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: PPC64, add HPT/SDR1 for -PR KVM

Allocate a page table and point SDR1 to it in order to support the -PR
PPC64 KVM mode. (The alternative, -HV mode, is available only on a small
set of mac

kvm tools: PPC64, add HPT/SDR1 for -PR KVM

Allocate a page table and point SDR1 to it in order to support the -PR
PPC64 KVM mode. (The alternative, -HV mode, is available only on a small
set of machines.)

This patch also removes the previous dependency on mapping guest RAM with
huge pages; PR KVM doesn't require them so the user isn't forced to use them.

A new option, '--hugetlbfs default', uses a default path for 16M pages for
HV mode, if required.

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

show more ...

kvm tools: Introduce KVM_IPC_VMSTATE IPC cmd

This can be used to get vm status information:

vm is running or paused.

Signed-off-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Pekka Enberg <pe

kvm tools: Introduce KVM_IPC_VMSTATE IPC cmd

This can be used to get vm status information:

vm is running or paused.

Signed-off-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Remove KVM_NR_CPUS

The KVM_NR_CPUS define is only really used to statically size the global
kvm_cpus array, which can just as easily be allocated on startup. There is
some checking of th

kvm tools: Remove KVM_NR_CPUS

The KVM_NR_CPUS define is only really used to statically size the global
kvm_cpus array, which can just as easily be allocated on startup. There is
some checking of the -c <nr cpus> value given against NR_CPUs but this is
later again checked against a dynamically-determined limit from
KVM_CAP_MAX_VCPUS anyway. The hardwired limit is arbitrary and not strictly
necessary.

This patch removes the #define, replacing the statically-sized array with
a malloc; the array is kvm->nrcpus+1 in size so that any iterator can halt
at the end (this is done in kvm_cpu__reboot, which doesn't have access to
a struct kvm* and therefore kvm->nrcpus).

An unused #define in x86/mptable.c is also removed.

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

show more ...

kvm tools: Add initial SPAPR PPC64 architecture support

This patch adds a new arch directory, powerpc, basic file structure, register
setup and where necessary stubs out arch-specific functions (e.g

kvm tools: Add initial SPAPR PPC64 architecture support

This patch adds a new arch directory, powerpc, basic file structure, register
setup and where necessary stubs out arch-specific functions (e.g. interrupts,
runloop exits) that later patches will provide. The target is an
SPAPR-compliant PPC64 machine (i.e. pSeries); there is no support for PPC32 or
'bare metal' PPC64 guests as yet. Subsequent patches implement the hcalls and
RTAS required to boot SPAPR pSeries kernels.

Memory is mapped from hugetlbfs (as that is currently required by upstream PPC64
HV-mode KVM). The mapping of a VRMA region is yet to be implemented; this is
only necessary on processors that don't support VRMA, e.g. <= P6. Work is
therefore needed to get this going on pre-P7 CPUs.

Processor state is set up as a guest kernel would expect (both primary and
secondaries), and SMP is fully supported.

Finally, support is added for simply loading flat binary kernels (plus initrd).
(bzImages are not used on PPC, and this series does not add zImage support or an
ELF loader.) The intention is to later support loading firmware such as SLOF.

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

show more ...