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 as to manage
carefully.
By providing a
On 2012-03-28 19:47, 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 use
On Wed, Mar 28, 2012 at 10:47 AM, Jan Kiszka wrote:
[...]
> +4.61 KVM_SET_MSI
> +
> +Capability: KVM_CAP_SET_MSI
> +Architectures: x86
> +Type: vm ioctl
> +Parameters: struct kvm_msi (in)
> +Returns: 0 on success, -1 on error
Is this the actual behavior? It looked to me like the successful
retur
On 2012-03-28 21:58, Eric Northup wrote:
> On Wed, Mar 28, 2012 at 10:47 AM, Jan Kiszka wrote:
> [...]
>> +4.61 KVM_SET_MSI
>> +
>> +Capability: KVM_CAP_SET_MSI
>> +Architectures: x86
>> +Type: vm ioctl
>> +Parameters: struct kvm_msi (in)
>> +Returns: 0 on success, -1 on error
>
> Is this the act
On Wed, Mar 28, 2012 at 07:47:31PM +0200, 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 limi
On 2012-03-29 17:39, Michael S. Tsirkin wrote:
> On Wed, Mar 28, 2012 at 07:47:31PM +0200, 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