linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: andre.przywara@arm.com (Andre Przywara)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/7] KVM: arm/arm64: gsi routing support
Date: Thu, 9 Jul 2015 16:25:50 +0100	[thread overview]
Message-ID: <559E927E.8040403@arm.com> (raw)
In-Reply-To: <023601d0ba54$c4d6e020$4e84a060$@samsung.com>

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
> 

  reply	other threads:[~2015-07-09 15:25 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-09  8:22 [PATCH v2 0/7] KVM: arm/arm64: gsi routing support Eric Auger
2015-07-09  8:22 ` [PATCH v2 1/7] KVM: api: introduce KVM_IRQ_ROUTING_EXTENDED_MSI Eric Auger
2015-07-10 22:42   ` Andre Przywara
2015-07-13  9:25     ` Eric Auger
2015-07-09  8:22 ` [PATCH v2 2/7] KVM: kvm_host: add devid in kvm_kernel_irq_routing_entry Eric Auger
2015-07-09  8:22 ` [PATCH v2 3/7] KVM: irqchip: convey devid to kvm_set_msi Eric Auger
2015-07-10 23:15   ` Andre Przywara
2015-07-17  7:27   ` Pavel Fedin
2015-07-17 10:09     ` Paolo Bonzini
2015-07-17 10:21       ` Pavel Fedin
2015-07-18 18:39         ` Eric Auger
2015-07-09  8:22 ` [PATCH v2 4/7] KVM: arm/arm64: enable irqchip routing Eric Auger
2015-07-10 23:15   ` Andre Przywara
2015-07-13  9:58     ` Eric Auger
2015-07-15  7:29       ` Pavel Fedin
2015-07-09  8:22 ` [PATCH v2 5/7] KVM: arm/arm64: build a default routing table Eric Auger
2015-07-09  8:22 ` [PATCH v2 6/7] KVM: arm/arm64: enable MSI routing Eric Auger
2015-07-10 23:16   ` Andre Przywara
2015-07-09  8:22 ` [PATCH v2 7/7] KVM: arm: implement kvm_set_msi by gsi direct mapping Eric Auger
2015-07-10 23:17   ` Andre Przywara
2015-07-31 12:59     ` Eric Auger
2015-08-02 20:23       ` Andre Przywara
2015-08-03  9:11         ` Eric Auger
2015-07-09 14:37 ` [PATCH v2 0/7] KVM: arm/arm64: gsi routing support Pavel Fedin
2015-07-09 15:25   ` Andre Przywara [this message]
2015-07-09 15:52     ` Pavel Fedin
2015-07-09 17:11       ` Eric Auger
2015-07-09 18:08         ` Pavel Fedin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=559E927E.8040403@arm.com \
    --to=andre.przywara@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).