All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@arm.com>
To: Pavel Fedin <p.fedin@samsung.com>,
	'Paolo Bonzini' <pbonzini@redhat.com>,
	'Christoffer Dall' <christoffer.dall@linaro.org>
Cc: "eric.auger@st.com" <eric.auger@st.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Marc Zyngier <Marc.Zyngier@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi
Date: Mon, 6 Jul 2015 16:37:58 +0100	[thread overview]
Message-ID: <559AA0D6.7070703@arm.com> (raw)
In-Reply-To: <024301d0b7f0$2b13b410$813b1c30$@samsung.com>

Hi Pavel,

On 06/07/15 14:32, Pavel Fedin wrote:
>  Hi!
> 
>>> Well, as we are about to implement this: yes. But the issue is that MSI
>>> injection and GSI routing code is generic PCI code in userland (at least
>>> in kvmtool, guess in QEMU, too), so I don't want to pull in any kind of
>>> ARM specific code in there. The idea is to always provide the device ID
>>> from the PCI code (for PCI devices it's just the B/D/F triplet), but
>>> only send it to the kernel if needed. Querying a KVM capability is
>>> perfectly fine for this IMO.
>>
>> Yes, I agree.
> 
>  Actually, we already have this capability, it's KVM_CAP_IRQ_ROUTING. If we have this capability,
> and want to use irqfds with GICv3, we need to set KVM_MSI_VALID_DEVID.

This is the connection that I don't like: We make the decision to
support a flag on a generic KVM interface dependent on some particular
device emulation (for some very specific architecture, also).

> And there is no other way to
> use irqfds with GICv3.

For now: yes, but I fail to see why the GICv3 is so special that is
justifies an extra handling in the KVM interrupt routing code. If it is
special, lets name it explicitly why: we need a device ID.

>  Just for example, this is what i have done in qemu:
> --- cut ---
> int kvm_irqchip_add_msi_route(KVMState *s, MSIMessage msg, PCIDevice *dev)
> {
>     struct kvm_irq_routing_entry kroute = {};
>     int virq;
> 
>     if (kvm_gsi_direct_mapping()) {
>         return kvm_arch_msi_data_to_gsi(msg.data);
>     }
> 
>     if (!kvm_gsi_routing_enabled()) {
>         return -ENOSYS;
>     }
> 
>     virq = kvm_irqchip_get_virq(s);
>     if (virq < 0) {
>         return virq;
>     }
> 
>     kroute.gsi = virq;
>     kroute.type = KVM_IRQ_ROUTING_MSI;
>     kroute.u.msi.address_lo = (uint32_t)msg.address;
>     kroute.u.msi.address_hi = msg.address >> 32;
>     kroute.u.msi.data = le32_to_cpu(msg.data);
>     kroute.flags = kvm_msi_flags;
>     if (kroute.flags & KVM_MSI_VALID_DEVID) {
>         kroute.u.msi.devid = (pci_bus_num(dev->bus) << 8) | dev->devfn;
>     }

Wouldn't:
    if (kvm_vm_check_extension(s, KVM_CAP_MSI_DEVID)) {
        kroute.flags = KVM_MSI_VALID_DEVID;
        kroute.u.msi.devid = (pci_bus_num(dev->bus) << 8) | dev->devfn;
    }

be saner (without a global variable)?
That would make the interface more consistent, with a new flag being
protected by a new capability.

Cheers,
Andre.

>     if (kvm_arch_fixup_msi_route(&kroute, msg.address, msg.data)) {
>         kvm_irqchip_release_virq(s, virq);
>         return -EINVAL;
>     }
> 
>     kvm_add_routing_entry(s, &kroute);
>     kvm_irqchip_commit_routes(s);
> 
>     return virq;
> }

WARNING: multiple messages have this Message-ID (diff)
From: andre.przywara@arm.com (Andre Przywara)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi
Date: Mon, 6 Jul 2015 16:37:58 +0100	[thread overview]
Message-ID: <559AA0D6.7070703@arm.com> (raw)
In-Reply-To: <024301d0b7f0$2b13b410$813b1c30$@samsung.com>

Hi Pavel,

On 06/07/15 14:32, Pavel Fedin wrote:
>  Hi!
> 
>>> Well, as we are about to implement this: yes. But the issue is that MSI
>>> injection and GSI routing code is generic PCI code in userland (at least
>>> in kvmtool, guess in QEMU, too), so I don't want to pull in any kind of
>>> ARM specific code in there. The idea is to always provide the device ID
>>> from the PCI code (for PCI devices it's just the B/D/F triplet), but
>>> only send it to the kernel if needed. Querying a KVM capability is
>>> perfectly fine for this IMO.
>>
>> Yes, I agree.
> 
>  Actually, we already have this capability, it's KVM_CAP_IRQ_ROUTING. If we have this capability,
> and want to use irqfds with GICv3, we need to set KVM_MSI_VALID_DEVID.

This is the connection that I don't like: We make the decision to
support a flag on a generic KVM interface dependent on some particular
device emulation (for some very specific architecture, also).

> And there is no other way to
> use irqfds with GICv3.

For now: yes, but I fail to see why the GICv3 is so special that is
justifies an extra handling in the KVM interrupt routing code. If it is
special, lets name it explicitly why: we need a device ID.

>  Just for example, this is what i have done in qemu:
> --- cut ---
> int kvm_irqchip_add_msi_route(KVMState *s, MSIMessage msg, PCIDevice *dev)
> {
>     struct kvm_irq_routing_entry kroute = {};
>     int virq;
> 
>     if (kvm_gsi_direct_mapping()) {
>         return kvm_arch_msi_data_to_gsi(msg.data);
>     }
> 
>     if (!kvm_gsi_routing_enabled()) {
>         return -ENOSYS;
>     }
> 
>     virq = kvm_irqchip_get_virq(s);
>     if (virq < 0) {
>         return virq;
>     }
> 
>     kroute.gsi = virq;
>     kroute.type = KVM_IRQ_ROUTING_MSI;
>     kroute.u.msi.address_lo = (uint32_t)msg.address;
>     kroute.u.msi.address_hi = msg.address >> 32;
>     kroute.u.msi.data = le32_to_cpu(msg.data);
>     kroute.flags = kvm_msi_flags;
>     if (kroute.flags & KVM_MSI_VALID_DEVID) {
>         kroute.u.msi.devid = (pci_bus_num(dev->bus) << 8) | dev->devfn;
>     }

Wouldn't:
    if (kvm_vm_check_extension(s, KVM_CAP_MSI_DEVID)) {
        kroute.flags = KVM_MSI_VALID_DEVID;
        kroute.u.msi.devid = (pci_bus_num(dev->bus) << 8) | dev->devfn;
    }

be saner (without a global variable)?
That would make the interface more consistent, with a new flag being
protected by a new capability.

Cheers,
Andre.

>     if (kvm_arch_fixup_msi_route(&kroute, msg.address, msg.data)) {
>         kvm_irqchip_release_virq(s, virq);
>         return -EINVAL;
>     }
> 
>     kvm_add_routing_entry(s, &kroute);
>     kvm_irqchip_commit_routes(s);
> 
>     return virq;
> }

WARNING: multiple messages have this Message-ID (diff)
From: Andre Przywara <andre.przywara@arm.com>
To: Pavel Fedin <p.fedin@samsung.com>,
	"'Paolo Bonzini'" <pbonzini@redhat.com>,
	"'Christoffer Dall'" <christoffer.dall@linaro.org>
Cc: "'Eric Auger'" <eric.auger@linaro.org>,
	"eric.auger@st.com" <eric.auger@st.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Marc Zyngier <Marc.Zyngier@arm.com>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi
Date: Mon, 6 Jul 2015 16:37:58 +0100	[thread overview]
Message-ID: <559AA0D6.7070703@arm.com> (raw)
In-Reply-To: <024301d0b7f0$2b13b410$813b1c30$@samsung.com>

Hi Pavel,

On 06/07/15 14:32, Pavel Fedin wrote:
>  Hi!
> 
>>> Well, as we are about to implement this: yes. But the issue is that MSI
>>> injection and GSI routing code is generic PCI code in userland (at least
>>> in kvmtool, guess in QEMU, too), so I don't want to pull in any kind of
>>> ARM specific code in there. The idea is to always provide the device ID
>>> from the PCI code (for PCI devices it's just the B/D/F triplet), but
>>> only send it to the kernel if needed. Querying a KVM capability is
>>> perfectly fine for this IMO.
>>
>> Yes, I agree.
> 
>  Actually, we already have this capability, it's KVM_CAP_IRQ_ROUTING. If we have this capability,
> and want to use irqfds with GICv3, we need to set KVM_MSI_VALID_DEVID.

This is the connection that I don't like: We make the decision to
support a flag on a generic KVM interface dependent on some particular
device emulation (for some very specific architecture, also).

> And there is no other way to
> use irqfds with GICv3.

For now: yes, but I fail to see why the GICv3 is so special that is
justifies an extra handling in the KVM interrupt routing code. If it is
special, lets name it explicitly why: we need a device ID.

>  Just for example, this is what i have done in qemu:
> --- cut ---
> int kvm_irqchip_add_msi_route(KVMState *s, MSIMessage msg, PCIDevice *dev)
> {
>     struct kvm_irq_routing_entry kroute = {};
>     int virq;
> 
>     if (kvm_gsi_direct_mapping()) {
>         return kvm_arch_msi_data_to_gsi(msg.data);
>     }
> 
>     if (!kvm_gsi_routing_enabled()) {
>         return -ENOSYS;
>     }
> 
>     virq = kvm_irqchip_get_virq(s);
>     if (virq < 0) {
>         return virq;
>     }
> 
>     kroute.gsi = virq;
>     kroute.type = KVM_IRQ_ROUTING_MSI;
>     kroute.u.msi.address_lo = (uint32_t)msg.address;
>     kroute.u.msi.address_hi = msg.address >> 32;
>     kroute.u.msi.data = le32_to_cpu(msg.data);
>     kroute.flags = kvm_msi_flags;
>     if (kroute.flags & KVM_MSI_VALID_DEVID) {
>         kroute.u.msi.devid = (pci_bus_num(dev->bus) << 8) | dev->devfn;
>     }

Wouldn't:
    if (kvm_vm_check_extension(s, KVM_CAP_MSI_DEVID)) {
        kroute.flags = KVM_MSI_VALID_DEVID;
        kroute.u.msi.devid = (pci_bus_num(dev->bus) << 8) | dev->devfn;
    }

be saner (without a global variable)?
That would make the interface more consistent, with a new flag being
protected by a new capability.

Cheers,
Andre.

>     if (kvm_arch_fixup_msi_route(&kroute, msg.address, msg.data)) {
>         kvm_irqchip_release_virq(s, virq);
>         return -EINVAL;
>     }
> 
>     kvm_add_routing_entry(s, &kroute);
>     kvm_irqchip_commit_routes(s);
> 
>     return virq;
> }

  parent reply	other threads:[~2015-07-06 15:26 UTC|newest]

Thread overview: 147+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-29 15:37 [PATCH 0/7] KVM: arm/arm64: gsi routing support Eric Auger
2015-06-29 15:37 ` Eric Auger
2015-06-29 15:37 ` Eric Auger
2015-06-29 15:37 ` [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi Eric Auger
2015-06-29 15:37   ` Eric Auger
2015-06-29 15:37   ` Eric Auger
2015-07-02  7:26   ` Pavel Fedin
2015-07-02  7:26     ` Pavel Fedin
2015-07-02  7:26     ` Pavel Fedin
2015-07-02  8:41     ` Pavel Fedin
2015-07-02  8:41       ` Pavel Fedin
2015-07-02 14:50       ` Eric Auger
2015-07-02 14:50         ` Eric Auger
2015-07-02 14:50         ` Eric Auger
2015-07-02 14:49     ` Eric Auger
2015-07-02 14:49       ` Eric Auger
2015-07-02 14:49       ` Eric Auger
2015-07-02 15:14       ` Andre Przywara
2015-07-02 15:14         ` Andre Przywara
2015-07-02 15:14         ` Andre Przywara
2015-07-02 15:22         ` Eric Auger
2015-07-02 15:22           ` Eric Auger
2015-07-02 15:39           ` Pavel Fedin
2015-07-02 15:39             ` Pavel Fedin
2015-07-02 15:39             ` Pavel Fedin
2015-07-02 15:41             ` Eric Auger
2015-07-02 15:41               ` Eric Auger
2015-07-03 15:29               ` Pavel Fedin
2015-07-03 15:29                 ` Pavel Fedin
2015-07-03 15:29                 ` Pavel Fedin
2015-07-03 15:42                 ` Eric Auger
2015-07-03 15:42                   ` Eric Auger
2015-07-03 15:42                   ` Eric Auger
2015-07-03  9:05     ` Andre Przywara
2015-07-03  9:05       ` Andre Przywara
2015-07-03  9:05       ` Andre Przywara
2015-07-03 15:53       ` Andre Przywara
2015-07-03 15:53         ` Andre Przywara
2015-07-03 15:53         ` Andre Przywara
2015-07-06  6:42       ` Pavel Fedin
2015-07-06  6:42         ` Pavel Fedin
2015-07-06  6:42         ` Pavel Fedin
2015-07-06  8:30         ` Andre Przywara
2015-07-06  8:30           ` Andre Przywara
2015-07-06  8:30           ` Andre Przywara
2015-07-06  9:30           ` Christoffer Dall
2015-07-06  9:30             ` Christoffer Dall
2015-07-06  9:30             ` Christoffer Dall
2015-07-06 10:05             ` Andre Przywara
2015-07-06 10:05               ` Andre Przywara
2015-07-06 10:05               ` Andre Przywara
2015-07-06 10:37               ` Christoffer Dall
2015-07-06 10:37                 ` Christoffer Dall
2015-07-06 10:37                 ` Christoffer Dall
2015-07-06 11:07                 ` Paolo Bonzini
2015-07-06 11:07                   ` Paolo Bonzini
2015-07-06 11:23                   ` Andre Przywara
2015-07-06 11:23                     ` Andre Przywara
2015-07-06 11:23                     ` Andre Przywara
2015-07-06 11:51                     ` Paolo Bonzini
2015-07-06 11:51                       ` Paolo Bonzini
2015-07-06 13:32                       ` Pavel Fedin
2015-07-06 13:32                         ` Pavel Fedin
2015-07-06 15:01                         ` Eric Auger
2015-07-06 15:01                           ` Eric Auger
2015-07-06 15:01                           ` Eric Auger
2015-07-06 15:52                           ` Andre Przywara
2015-07-06 15:52                             ` Andre Przywara
2015-07-06 15:52                             ` Andre Przywara
2015-07-06 17:02                             ` Eric Auger
2015-07-06 17:02                               ` Eric Auger
2015-07-07  7:23                             ` Pavel Fedin
2015-07-07  7:23                               ` Pavel Fedin
2015-07-07  7:23                               ` Pavel Fedin
2015-07-07  7:43                               ` Eric Auger
2015-07-07  7:43                                 ` Eric Auger
2015-07-07  7:43                                 ` Eric Auger
2015-07-06 15:37                         ` Andre Przywara [this message]
2015-07-06 15:37                           ` Andre Przywara
2015-07-06 15:37                           ` Andre Przywara
2015-07-06 15:54                           ` Paolo Bonzini
2015-07-06 15:54                             ` Paolo Bonzini
2015-07-06 15:54                             ` Paolo Bonzini
2015-07-06 16:08                             ` Andre Przywara
2015-07-06 16:08                               ` Andre Przywara
2015-07-06 16:08                               ` Andre Przywara
2015-07-07  7:16                           ` Pavel Fedin
2015-07-07  7:16                             ` Pavel Fedin
2015-07-07  7:16                             ` Pavel Fedin
2015-07-07 10:02                             ` Andre Przywara
2015-07-07 10:02                               ` Andre Przywara
2015-07-07 10:02                               ` Andre Przywara
2015-07-07 10:57                               ` Pavel Fedin
2015-07-07 10:57                                 ` Pavel Fedin
2015-07-07 10:57                                 ` Pavel Fedin
2015-07-06 12:08                     ` Christoffer Dall
2015-07-06 12:08                       ` Christoffer Dall
2015-07-06 13:33                       ` Pavel Fedin
2015-07-06 13:33                         ` Pavel Fedin
2015-07-06 13:33                         ` Pavel Fedin
2015-07-06 15:09                       ` Andre Przywara
2015-07-06 15:09                         ` Andre Przywara
2015-07-06 15:09                         ` Andre Przywara
2015-06-29 15:37 ` [PATCH 2/7] KVM: kvm_host: add kvm_extended_msi Eric Auger
2015-06-29 15:37   ` Eric Auger
2015-06-29 15:37   ` Eric Auger
2015-07-02 17:03   ` Andre Przywara
2015-07-02 17:03     ` Andre Przywara
2015-07-02 17:03     ` Andre Przywara
2015-06-29 15:37 ` [PATCH 3/7] KVM: irqchip: convey devid to kvm_set_msi Eric Auger
2015-06-29 15:37   ` Eric Auger
2015-06-29 15:37   ` Eric Auger
2015-06-29 15:37 ` [PATCH 4/7] KVM: arm/arm64: enable irqchip routing Eric Auger
2015-06-29 15:37   ` Eric Auger
2015-06-29 15:37   ` Eric Auger
2015-06-30 13:39   ` Andre Przywara
2015-06-30 13:39     ` Andre Przywara
2015-06-30 13:39     ` Andre Przywara
2015-06-30 14:02     ` Eric Auger
2015-06-30 14:02       ` Eric Auger
2015-06-30 14:02       ` Eric Auger
2015-06-29 15:37 ` [PATCH 5/7] KVM: arm/arm64: build a default routing table Eric Auger
2015-06-29 15:37   ` Eric Auger
2015-06-29 15:37   ` Eric Auger
2015-06-29 15:37 ` [PATCH 6/7] KVM: arm/arm64: enable MSI routing Eric Auger
2015-06-29 15:37   ` Eric Auger
2015-06-29 15:37   ` Eric Auger
2015-06-29 15:37 ` [PATCH 7/7] KVM: arm: implement kvm_set_msi by gsi direct mapping Eric Auger
2015-06-29 15:37   ` Eric Auger
2015-06-29 15:37   ` Eric Auger
2015-07-02  7:53   ` Pavel Fedin
2015-07-02  7:53     ` Pavel Fedin
2015-07-02 15:02     ` Eric Auger
2015-07-02 15:02       ` Eric Auger
2015-07-02 15:02       ` Eric Auger
2015-07-02 15:37       ` Pavel Fedin
2015-07-02 15:37         ` Pavel Fedin
2015-07-02 15:37         ` Pavel Fedin
2015-07-02 17:10   ` Andre Przywara
2015-07-02 17:10     ` Andre Przywara
2015-07-02 17:10     ` Andre Przywara
2015-07-03  5:34     ` Eric Auger
2015-07-03  5:34       ` Eric Auger
2015-07-03  5:34       ` Eric Auger
2015-07-05 19:40 ` [PATCH 0/7] KVM: arm/arm64: gsi routing support Christoffer Dall
2015-07-05 19:40   ` Christoffer Dall
2015-07-05 19:40   ` Christoffer Dall

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=559AA0D6.7070703@arm.com \
    --to=andre.przywara@arm.com \
    --cc=Marc.Zyngier@arm.com \
    --cc=christoffer.dall@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=linux-kernel@vger.kernel.org \
    --cc=p.fedin@samsung.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.