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

virtio: Add reset() callback

When the guest writes a status of 0, the device should be reset. Add a
reset() callback for the transport layer to reset all queues and their
ioeventfd.

Signed-off-by:

virtio: Add reset() callback

When the guest writes a status of 0, the device should be reset. Add a
reset() callback for the transport layer to reset all queues and their
ioeventfd.

Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Julien Thierry <julien.thierry@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

virtio: Add exit_vq() callback

Virtio allows to reset individual virtqueues. For legacy devices, it's
done by writing an address of 0 into the PFN register. Modern devices have
an "enable" register.

virtio: Add exit_vq() callback

Virtio allows to reset individual virtqueues. For legacy devices, it's
done by writing an address of 0 into the PFN register. Modern devices have
an "enable" register. Add an exit_vq() callback to all devices. A lot more
work is required by each device to clean up their virtqueue state, and by
the core to reset things like MSI routes and ioeventfds.

Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Julien Thierry <julien.thierry@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

virtio: Add get_vq() callback

To ease future changes to the core, replace get_pfn_vq() with get_vq().
This way adding new generic operation on virtqueues won't require
modifying every virtio device.

virtio: Add get_vq() callback

To ease future changes to the core, replace get_pfn_vq() with get_vq().
This way adding new generic operation on virtqueues won't require
modifying every virtio device.

Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Julien Thierry <julien.thierry@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

virtio: Implement notify_status

Modern virtio require proper status handling and reset. A "notify_status"
callback is already present in the virtio ops, but isn't implemented by
any device. Instead

virtio: Implement notify_status

Modern virtio require proper status handling and reset. A "notify_status"
callback is already present in the virtio ops, but isn't implemented by
any device. Instead they currently use "set_guest_feature" to reset the
device and deal with endianess. This isn't sufficient for proper device
reset, so add the notify_status callback to all devices that need it.

To add useful hints like "start" and "stop", extend the status variable to
32-bits.

Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
[Julien T: Remove VIRTIO_CONFIG_S_NEEDS_RESET from config mask, as
it is virtio v1+ macro and kvmtool only implements v0.9, this
macro should not be referenced for now]
Signed-off-by: Julien Thierry <julien.thierry@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

virtio/pci: Register a single eventfd for vhost

Vhost supports a single eventfd as the kick mechanism. Registering a
second one will override the first. To ensure vhost works with our
virtio-pci, on

virtio/pci: Register a single eventfd for vhost

Vhost supports a single eventfd as the kick mechanism. Registering a
second one will override the first. To ensure vhost works with our
virtio-pci, only register the kick eventfd that is used by the guest.

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

virtio/pci: Use port I/O for configuration registers by default

Modern virtio PCI is allowed to use both memory and I/O BARs for the
config space, but legacy devices must use I/O for BAR0, as specif

virtio/pci: Use port I/O for configuration registers by default

Modern virtio PCI is allowed to use both memory and I/O BARs for the
config space, but legacy devices must use I/O for BAR0, as specified by
Virtio v1.0 cs04:

4.1.5.1.1.1 Legacy Interface: A Note on Device Layout Detection
"Transitional devices MUST expose the Legacy Interface in I/O space in
BAR0."

What virtio calls "I/O space" is most certainly port I/O, as hinted by the
discussion in 4.1.4 Virtio Structure PCI Capabilities, where it
distinguishes "memory BARs" from "I/O BARs". This is also the conclusion
made by SeaBIOS [1], which only looks for port I/O in BAR0 when driving a
transitional device.

I think MMIO was made the default by a463650caad6 ("kvm tools: pci: add
MMIO interface to virtio-pci devices") to support ARM targets, but we
support PIO as well as MMIO nowadays. So let's make the legacy virtio
implementation comply with the specification and use port I/O for BAR0.

[1] https://patchwork.kernel.org/patch/10038927/

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

show more ...

virtio: Save negotiated features

We're going to need the features bits negotiated between host and guest in
the core code. Save them in the virtio_device structure.

Signed-off-by: Jean-Philippe Bru

virtio: Save negotiated features

We're going to need the features bits negotiated between host and guest in
the core code. Save them in the virtio_device structure.

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

show more ...

Add GICv2m support

GICv2m is a small extension to the GICv2 architecture, specified in the
Server Base System Architecture (SBSA). It adds a set of register to
converts MSIs into SPIs, effectively e

Add GICv2m support

GICv2m is a small extension to the GICv2 architecture, specified in the
Server Base System Architecture (SBSA). It adds a set of register to
converts MSIs into SPIs, effectively enabling MSI support for pre-GICv3
platforms.

Implement a GICv2m emulation entirely in userspace. Add a thin translation
layer in irq.c to catch the MSI->SPI routing setup of the guest, and then
transform irqfd injection of MSI into the associated SPI. There shouldn't
be any significant runtime overhead compared to gicv3-its.

The device can be enabled by passing "--irqchip gicv2m" to kvmtool.

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

show more ...

extend GSI IRQ routing to take a device ID

For ITS emulation we need the device ID along with the MSI payload
and doorbell address to identify an MSI, so we need to put it in the
GSI IRQ routing tab

extend GSI IRQ routing to take a device ID

For ITS emulation we need the device ID along with the MSI payload
and doorbell address to identify an MSI, so we need to put it in the
GSI IRQ routing table too.
There is a per-VM capability by which the kernel signals the need for
a device ID, so check this and put the device ID into the routing
table if needed.
For PCI devices we take the bus/device/function triplet and and that
to the routing setup call.

Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

PCI: inject PCI device ID on MSI injection

The ITS emulation requires a unique device ID to be passed along the
MSI payload when kvmtool wants to trigger an MSI in the guest.
According to the propos

PCI: inject PCI device ID on MSI injection

The ITS emulation requires a unique device ID to be passed along the
MSI payload when kvmtool wants to trigger an MSI in the guest.
According to the proposed changes to the interface add the PCI
bus/device/function triple to the structure passed with the ioctl.
Check the respective capability before actually adding the device ID
to the kvm_msi struct.

Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

PCI: Only allocate IRQ routing entry when available

If we need to inject an MSI into the guest, we rely at the moment on a
working GSI MSI routing functionality. However we can get away without
IRQ

PCI: Only allocate IRQ routing entry when available

If we need to inject an MSI into the guest, we rely at the moment on a
working GSI MSI routing functionality. However we can get away without
IRQ routing, if the host supports MSI injection via the KVM_SIGNAL_MSI
ioctl.
So we try the GSI routing first, but if that fails due to a missing
IRQ routing functionality, we fall back to KVM_SIGNAL_MSI (if that is
supported).

Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

MSI-X: update GSI routing after changed MSI-X configuration

When we set up GSI routing to map MSIs to KVM's GSI numbers, we
write the current device's MSI setup into the kernel routing table.
Howeve

MSI-X: update GSI routing after changed MSI-X configuration

When we set up GSI routing to map MSIs to KVM's GSI numbers, we
write the current device's MSI setup into the kernel routing table.
However the device driver in the guest can use PCI configuration space
accesses to change the MSI configuration (address and/or payload data).
Whenever this happens after we have setup the routing table already,
we must amend the previously sent data.
So when MSI-X PCI config space accesses write address or payload,
find the associated GSI number and the matching routing table entry
and update the kernel routing table (only if the data has changed).

This fixes vhost-net, where the queue's IRQFD was setup before the
MSI vectors.

To avoid issues, we ignore writes to the PBA region. The spec says:
"Software should never write, and should only read Pending Bits.
If software writes to Pending Bits, the result is undefined."

Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

irq: move IRQ routing into irq.c

The current IRQ routing code in x86/irq.c is mostly implementing a
generic KVM interface which other architectures may use too.
Move the code to set up an MSI route

irq: move IRQ routing into irq.c

The current IRQ routing code in x86/irq.c is mostly implementing a
generic KVM interface which other architectures may use too.
Move the code to set up an MSI route into the generic irq.c file and
guard it with the KVM_CAP_IRQ_ROUTING capability to return an error
if the kernel does not support interrupt routing.
This also removes the dummy implementations for all other
architectures and only leaves the x86 specific code in x86/irq.c.

Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

kvmtool: vhost-net: fix ioeventfd registration

On registering the ioeventfds for the virtio-pci device we cover both
the I/O ports and the MMIO BAR.
But as the current code advertises both as PIO, t

kvmtool: vhost-net: fix ioeventfd registration

On registering the ioeventfds for the virtio-pci device we cover both
the I/O ports and the MMIO BAR.
But as the current code advertises both as PIO, the host kernel gets
the wrong bus number for the MMIO region.
Fix the issue by marking only the actual PIO area as PIO.
This fixes vhost-net on x86.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

kvmtool: don't use PCI config space IRQ line field

In PCI config space there is an interrupt line field (offset 0x3f),
which is used to initially communicate the IRQ line number from
firmware to the

kvmtool: don't use PCI config space IRQ line field

In PCI config space there is an interrupt line field (offset 0x3f),
which is used to initially communicate the IRQ line number from
firmware to the OS. _Hardware_ should never use this information,
as the OS is free to write any information in there.
But kvmtool uses this number when it triggers IRQs in the guest,
which fails starting with Linux 3.19-rc1, where the PCI layer starts
writing the virtual IRQ number in there.

Fix that by storing the IRQ number in a separate field in
struct virtio_pci, which is independent from the PCI config space
and cannot be influenced by the guest.
This fixes ARM/ARM64 guests using PCI with newer kernels.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

kvmtool: Fix length of ioevent for VIRTIO_PCI_QUEUE_NOTIFY

VIRTIO_PCI_QUEUE_NOTIFY is 16-bit and iowrite16 is used in
drivers/virtio/virtio_pci.c to notify the other side.

If the size doesn't match

kvmtool: Fix length of ioevent for VIRTIO_PCI_QUEUE_NOTIFY

VIRTIO_PCI_QUEUE_NOTIFY is 16-bit and iowrite16 is used in
drivers/virtio/virtio_pci.c to notify the other side.

If the size doesn't match notification via mmio write will fail.

Signed-off-by: Andreas Herrmann <andreas.herrmann@caviumnetworks.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

kvm tools: Handle virtio/pci I/O space as little endian

It doesn't work on big endian hosts as is.

Signed-off-by: David Daney <david.daney@cavium.com>
Signed-off-by: Andreas Herrmann <andreas.herrm

kvm tools: Handle virtio/pci I/O space as little endian

It doesn't work on big endian hosts as is.

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

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

kvmtool: pass trapped vcpu to MMIO accessors

In order to be able to find out about the endianness of a virtual
CPU, it is necessary to pass a pointer to the kvm_cpu structure
down to the MMIO access

kvmtool: pass trapped vcpu to MMIO accessors

In order to be able to find out about the endianness of a virtual
CPU, it is necessary to pass a pointer to the kvm_cpu structure
down to the MMIO accessors.

This patch just pushes such pointer as far as required for the
MMIO accessors to have a play with the vcpu.

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

show more ...

kvm tools: mark our PCI card as PIO and MMIO able

A recent -next patch named "PCI: Ignore BAR contents when
firmware left decoding disabled" has pointed out that PCI
cards are supposed to declare th

kvm tools: mark our PCI card as PIO and MMIO able

A recent -next patch named "PCI: Ignore BAR contents when
firmware left decoding disabled" has pointed out that PCI
cards are supposed to declare that they have either PIO or
MMIO BARs by disabling them if it didn't.

Fix it by correctly marking our emulated PCI card as PIO/MMIO
enabled.

Signed-off-by: Sasha Levin <sasha.levin@oracle.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 ...