irq: add irqfd helpers

Add helpers to add and remove IRQFD routing for both irqchips and MSIs.
We have to make a special case of IRQ lines on ARM where the
initialisation order goes like this:

(1)

irq: add irqfd helpers

Add helpers to add and remove IRQFD routing for both irqchips and MSIs.
We have to make a special case of IRQ lines on ARM where the
initialisation order goes like this:

(1) Devices reserve their IRQ lines
(2) VGIC is setup with VGIC_CTRL_INIT (in a late_init call)
(3) MSIs are reserved lazily, when the guest needs them

Since we cannot setup IRQFD before (2), store the IRQFD routing for IRQ
lines temporarily until we're ready to submit them.

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

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

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

irq: add irq__get_nr_allocated_lines

The ARM GIC emulation needs to be told the number of interrupts
it has to support. As commit 1c262fa1dc7bc ("kvm tools: irq: make
irq__alloc_line generic") made

irq: add irq__get_nr_allocated_lines

The ARM GIC emulation needs to be told the number of interrupts
it has to support. As commit 1c262fa1dc7bc ("kvm tools: irq: make
irq__alloc_line generic") made the interrupt counter private,
add a new accessor returning the number of interrupt lines we've
allocated so far.

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

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: Use IRQ line 5+ for devices

IRQ lines 3 and 4 are used by the serial device, assigning them to other
devices as well hurts performance. We should avoid shared IRQs if possible.

Signed-of

kvm tools: Use IRQ line 5+ for devices

IRQ lines 3 and 4 are used by the serial device, assigning them to other
devices as well hurts performance. We should avoid shared IRQs if possible.

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

show more ...

kvm tools: Simplify msi message handling

This patch simplifies passing around msi messages by using
'struct kvm_irq_routing_msi' for storing of msi messages instead
of passing all msi parameters aro

kvm tools: Simplify msi message handling

This patch simplifies passing around msi messages by using
'struct kvm_irq_routing_msi' for storing of msi messages instead
of passing all msi parameters around.

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

show more ...

kvm tools: Fix IRQ mapping

This thread fixes two issues:
- Slave IRQCHIP was mapped wrong, this caused all IRQs which belong
to it to be ignored (breaking such things as the mouse).
- Line 2 was b

kvm tools: Fix IRQ mapping

This thread fixes two issues:
- Slave IRQCHIP was mapped wrong, this caused all IRQs which belong
to it to be ignored (breaking such things as the mouse).
- Line 2 was being mapped, since it's the link between slave and master
IRQCHIPs it shouldn't be.

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

show more ...

kvm tools: Use GSI routing

Map GSIs manually when starting the guest.
This will allow us mapping new GSIs for MSIX in the future.

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

kvm tools: Use GSI routing

Map GSIs manually when starting the guest.
This will allow us mapping new GSIs for MSIX in the future.

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

show more ...

kvm tools: Fix up PCI pin assignment to conform specification

Only 4 pins are allowed for every PCI compilant device as per PCI 2.2 spec
Section 2.2.6 ("Interrupt Pins"). Multifunctional devices can

kvm tools: Fix up PCI pin assignment to conform specification

Only 4 pins are allowed for every PCI compilant device as per PCI 2.2 spec
Section 2.2.6 ("Interrupt Pins"). Multifunctional devices can use up to all
INTA#,B#,C#,D# pins, for our single function devices pin INTA# is enough.

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

show more ...

kvm tools: Introduce IRQ registry

Instead of having static definitions of devices, Use a
dynamic registry of pci devices.

The structure is a rbtree which holds device types (net,
blk, etc). Each de

kvm tools: Introduce IRQ registry

Instead of having static definitions of devices, Use a
dynamic registry of pci devices.

The structure is a rbtree which holds device types (net,
blk, etc). Each device entry holds a list of IRQ lines
associated with that device (pin).

Devices dynamically register upon initialization, and receive
a set of: device id, irq pin and irq line.

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

show more ...