Subject: [PATCH v2 0/7] KVM: arm/arm64: gsi routing support

From: [email-masked] (Andre Przywara)
Date: Thu, 9 Jul 2015 16:25:50 +0100

Hi Pavel,

On 09/07/15 15:37, Pavel Fedin wrote:
>  Hello!
> 
>> v1 -> v2:
>> - user API changed:
>>   x devid id passed in kvm_irq_routing_msi
>>   x kept the new routing entry type: KVM_IRQ_ROUTING_EXTENDED_MSI
> 
>  Andre, you never replied to my last comment to the previous series.

Oh dear, my draft folder again :-( Sorry for that!

> Are you going to do the same
> change in your MSI API? Otherwise:
> 1. KVM_IRQ_LINE - we have completely own convention. Well, this was already done before us, we
> cannot fix it.
> 2. KVM_SIGNAL_MSI - we use VALID_DEVID flag plus devid

Yes, because there is already a flag value and no other way to specify
this, in contrast to ...

> 3. KVM_SET_GSI_ROUTING - we use KVM_IRQ_ROUTING_EXTENDED_MSI plus devid

Here we already have a type field with some users, so lets piggy-back on
this.

Both ioctl extensions are coupled with a per-VM capability to let
userland know that it needs to provide a device ID.

>  Don't (2) and (3) together still look bad? Since we agreed on not using flags, i would suggest to
> have KVM_SIGNAL_EXTENDED_MSI counterpart, which also doesn't use flags.

Using flags on its own (without an explicit capability) is what I
opposed against, not flags in general. After all, that's what they are
meant for, right? In case of KVM_SET_GSI_ROUTING it just seems awkward
to me to use a flag when a different type would do as well.

But after all, I don't have a strong opinion on that matter, so if
others prefer using a flag I am also fine with that.

Poka,
Andre.

>  I know, we were already talking about it, so, if this gets ignored for the second time, i assume
> the Architects decided that fancy APIs are cool, and i promise to stop this.
> 
> Kind regards,
> Pavel Fedin
> Expert Engineer
> Samsung Electronics Research center Russia
>