Re: [PATCH v4] KVM: Introduce direct MSI message injection for in-kernel irqchips

[Avi Kivity <avi@redhat.com>]

On 03/29/2012 09:14 PM, Jan Kiszka wrote:
> Currently, MSI messages can only be injected to in-kernel irqchips by
> defining a corresponding IRQ route for each message. This is not only
> unhandy if the MSI messages are generated "on the fly" by user space,
> IRQ routes are a limited resource that user space has to manage
> carefully.
>
> By providing a direct injection path, we can both avoid using up limited
> resources and simplify the necessary steps for user land.
>
> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
> index 81ff39f..ed27d1b 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -1482,6 +1482,27 @@ See KVM_ASSIGN_DEV_IRQ for the data structure.  The target device is specified
>  by assigned_dev_id.  In the flags field, only KVM_DEV_ASSIGN_MASK_INTX is
>  evaluated.
>  
> +4.61 KVM_SIGNAL_MSI
> +
> +Capability: KVM_CAP_SIGNAL_MSI
> +Architectures: x86
> +Type: vm ioctl
> +Parameters: struct kvm_msi (in)
> +Returns: >0 on delivery, 0 if guest blocked the MSI, and -1 on error
> +
> +Directly inject a MSI message. Only valid with in-kernel irqchip that handles
> +MSI messages.
> +
> +struct kvm_msi {
> +	__u32 address_lo;
> +	__u32 address_hi;
> +	__u32 data;
> +	__u32 flags;
> +	__u8  pad[16];
> +};
> +
> +No flags are defined so far. The corresponding field must be 0.
>

There are two ways in which this can be generalized:

struct kvm_general_irq {
      __u32 type; // line | MSI
      __u32 op;  // raise/lower/trigger
      union {
                 ... line;
                 struct kvm_msi msi;
      }
};

so we have a single ioctl for all interrupt handling.  This allows
eventual removal of the line-oriented ioctls.

The other alternative is to have a dma interface, similar to the kvm_run
mmio interface but with the kernel acting as destination.  The advantage
here is that we can handle dma from a device to any kernel-emulated
device, not just the APIC MSI range.  A downside is that we can't return
values related to interrupt coalescing.

A performance note: delivering an interrupt needs to search all vcpus
for an APIC ID match.  The previous plan was to cache (or pre-calculate)
this lookup in the irq routing table.  Now it looks like we'll need a
separate cache for this.

(yes, I said on the call I don't anticipate objections but preparing to
apply a patch always triggers more critical thinking)

-- 
error compiling committee.c: too many arguments to function