From: Andre Przywara <andre.przywara@arm.com>
To: Eric Auger <eric.auger@linaro.org>,
"eric.auger@st.com" <eric.auger@st.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
Marc Zyngier <Marc.Zyngier@arm.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>
Subject: Re: [PATCH v2 3/7] KVM: irqchip: convey devid to kvm_set_msi
Date: Sat, 11 Jul 2015 00:15:40 +0100 [thread overview]
Message-ID: <55A0521C.1040605@arm.com> (raw)
In-Reply-To: <1436430137-24205-4-git-send-email-eric.auger@linaro.org>
On 09/07/15 09:22, Eric Auger wrote:
> on ARM, a devid field is populated in kvm_msi struct in case the
> flag is set to KVM_MSI_VALID_DEVID. Let's populate the corresponding
> kvm_kernel_irq_routing_entry devid field and set the msi type to
> KVM_IRQ_ROUTING_EXTENDED_MSI.
>
> Signed-off-by: Eric Auger <eric.auger@linaro.org>
> ---
> virt/kvm/irqchip.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/virt/kvm/irqchip.c b/virt/kvm/irqchip.c
> index 21c1424..e678f8a 100644
> --- a/virt/kvm/irqchip.c
> +++ b/virt/kvm/irqchip.c
> @@ -72,9 +72,17 @@ int kvm_send_userspace_msi(struct kvm *kvm, struct kvm_msi *msi)
> {
> struct kvm_kernel_irq_routing_entry route;
>
> - if (!irqchip_in_kernel(kvm) || msi->flags != 0)
> + if (!irqchip_in_kernel(kvm))
> return -EINVAL;
>
> + if (msi->flags & KVM_MSI_VALID_DEVID) {
> + route.devid = msi->devid;
> + route.type = KVM_IRQ_ROUTING_EXTENDED_MSI;
> + } else if (!msi->flags)
> + return -EINVAL;
I think we get away without using the extended type on the kernel side.
Within the kernel we don't have an ABI that we have to stick to forever,
so we can simplify things by re-using the existing type (no need to
check for both MSI types later).
So we always set the device ID, the only code that looks at it later is
the ITS emulation anyway, any other code path simply ignores that.
To be honest I am not 100% sure that is actually better, but I had
hacked it in a way where I didn't need it.
Also have a look at the other comments in the following patches for
clarification.
Cheers,
Andre.
> +
> + /* historically the route.type was not set */
> +
> route.msi.address_lo = msi->address_lo;
> route.msi.address_hi = msi->address_hi;
> route.msi.data = msi->data;
>
next prev parent reply other threads:[~2015-07-10 23:15 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 [this message]
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
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=55A0521C.1040605@arm.com \
--to=andre.przywara@arm.com \
--cc=Marc.Zyngier@arm.com \
--cc=eric.auger@linaro.org \
--cc=eric.auger@st.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=pbonzini@redhat.com \
/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).