From: Andre Przywara <andre.przywara@arm.com>
To: Pavel Fedin <p.fedin@samsung.com>,
'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>,
"christoffer.dall@linaro.org" <christoffer.dall@linaro.org>,
"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Cc: "pbonzini@redhat.com" <pbonzini@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi
Date: Fri, 3 Jul 2015 16:53:50 +0100 [thread overview]
Message-ID: <5596B00E.2020706@arm.com> (raw)
In-Reply-To: <5596503E.6040902@arm.com>
Hi,
On 03/07/15 10:05, Andre Przywara wrote:
> Hi Pavel,
>
> On 02/07/15 08:26, Pavel Fedin wrote:
>> Hello!
>>
>>> -----Original Message-----
>>> From: kvm-owner@vger.kernel.org [mailto:kvm-owner@vger.kernel.org] On Behalf Of Eric Auger
>>> Sent: Monday, June 29, 2015 6:37 PM
>>> To: eric.auger@st.com; eric.auger@linaro.org; linux-arm-kernel@lists.infradead.org;
>>> marc.zyngier@arm.com; christoffer.dall@linaro.org; andre.przywara@arm.com;
>>> kvmarm@lists.cs.columbia.edu; kvm@vger.kernel.org
>>> Cc: linux-kernel@vger.kernel.org; patches@linaro.org; p.fedin@samsung.com; pbonzini@redhat.com
>>> Subject: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi
>>>
>>> On ARM, the MSI msg (address and data) comes along with
>>> out-of-band device ID information. The device ID encodes the device
>>> that composes the MSI msg. Let's create a new routing entry type,
>>> dubbed KVM_IRQ_ROUTING_EXTENDED_MSI and use the __u32 pad space
>>> to convey the device ID.
>>>
>>> Signed-off-by: Eric Auger <eric.auger@linaro.org>
>>>
>>> ---
>>>
>>> RFC -> PATCH
>>> - remove kvm_irq_routing_extended_msi and use union instead
>>> ---
>>> Documentation/virtual/kvm/api.txt | 9 ++++++++-
>>> include/uapi/linux/kvm.h | 6 +++++-
>>> 2 files changed, 13 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
>>> index d20fd94..6426ae9 100644
>>> --- a/Documentation/virtual/kvm/api.txt
>>> +++ b/Documentation/virtual/kvm/api.txt
>>> @@ -1414,7 +1414,10 @@ struct kvm_irq_routing_entry {
>>> __u32 gsi;
>>> __u32 type;
>>> __u32 flags;
>>> - __u32 pad;
>>> + union {
>>> + __u32 pad;
>>> + __u32 devid;
>>> + };
>>> union {
>>> struct kvm_irq_routing_irqchip irqchip;
>>> struct kvm_irq_routing_msi msi;
>>
>> devid is actually a part of MSI bunch. Shouldn't it be a part of struct kvm_irq_routing_msi then?
>> It also has reserved pad.
>>
>>> @@ -1427,6 +1430,10 @@ struct kvm_irq_routing_entry {
>>> #define KVM_IRQ_ROUTING_IRQCHIP 1
>>> #define KVM_IRQ_ROUTING_MSI 2
>>> #define KVM_IRQ_ROUTING_S390_ADAPTER 3
>>> +#define KVM_IRQ_ROUTING_EXTENDED_MSI 4
>>> +
>>> +In case of KVM_IRQ_ROUTING_EXTENDED_MSI routing type, devid is used to convey
>>> +the device ID.
>>>
>>> No flags are specified so far, the corresponding field must be set to zero.
>>
>> What if we use KVM_MSI_VALID_DEVID flag instead of new KVM_IRQ_ROUTING_EXTENDED_MSI definition? I
>> believe this would make an API more consistent and introduce less new definitions.
>
> I like this approach, but it runs into problems:
> As you read above the current documentation says that the flags field
> must be zero and the current KVM_SET_GSI_ROUTING handler bails out if it
> isn't. So userland would need to know whether it's safe to set that
> field. Introducing a new KVM_CAP_... value seems overkill if we could
> just have a new routing entry type. So we could still reuse the existing
> struct kvm_irq_routing_msi (and extend that with the devid field), but
> we would have to add a new routing type number.
> Maybe we could collapse this into the existing MSI type + flag when
> handing it further down the kernel?
FWIW, I gave this a try, this doesn't look to bad. I carried the new
type down till virt/kvm/arm/vgic.c:kvm_set_routing_entry(), where the
EXTENDED type got turned back into the normal MSI type while setting the
flag in the internal struct kvm_kernel_irq_routing_entry. This keeps the
new type only to the userland facing side, with the kernel code staying
mostly the same.
Together with a new KVM_CAP_MSIS_REQUIRE_DEVID capability I can now
drive both GICv2M and ITS emulation from the same userland base in a
sane manner.
If someone wants to have a look now, tell me, otherwise I will wait for
Eric's upcoming code drop and comment on that then.
Cheers,
Andre.
>
> Cheers,
> Andre.
>
>>
>>>
>>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
>>> index 2a23705..8484681 100644
>>> --- a/include/uapi/linux/kvm.h
>>> +++ b/include/uapi/linux/kvm.h
>>> @@ -841,12 +841,16 @@ struct kvm_irq_routing_s390_adapter {
>>> #define KVM_IRQ_ROUTING_IRQCHIP 1
>>> #define KVM_IRQ_ROUTING_MSI 2
>>> #define KVM_IRQ_ROUTING_S390_ADAPTER 3
>>> +#define KVM_IRQ_ROUTING_EXTENDED_MSI 4
>>>
>>> struct kvm_irq_routing_entry {
>>> __u32 gsi;
>>> __u32 type;
>>> __u32 flags;
>>> - __u32 pad;
>>> + union {
>>> + __u32 pad;
>>> + __u32 devid;
>>> + };
>>> union {
>>> struct kvm_irq_routing_irqchip irqchip;
>>> struct kvm_irq_routing_msi msi;
>>> --
>>> 1.9.1
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>> Kind regards,
>> Pavel Fedin
>> Expert Engineer
>> Samsung Electronics Research center Russia
>>
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: Fri, 3 Jul 2015 16:53:50 +0100 [thread overview]
Message-ID: <5596B00E.2020706@arm.com> (raw)
In-Reply-To: <5596503E.6040902@arm.com>
Hi,
On 03/07/15 10:05, Andre Przywara wrote:
> Hi Pavel,
>
> On 02/07/15 08:26, Pavel Fedin wrote:
>> Hello!
>>
>>> -----Original Message-----
>>> From: kvm-owner at vger.kernel.org [mailto:kvm-owner at vger.kernel.org] On Behalf Of Eric Auger
>>> Sent: Monday, June 29, 2015 6:37 PM
>>> To: eric.auger at st.com; eric.auger at linaro.org; linux-arm-kernel at lists.infradead.org;
>>> marc.zyngier at arm.com; christoffer.dall at linaro.org; andre.przywara at arm.com;
>>> kvmarm at lists.cs.columbia.edu; kvm at vger.kernel.org
>>> Cc: linux-kernel at vger.kernel.org; patches at linaro.org; p.fedin at samsung.com; pbonzini at redhat.com
>>> Subject: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi
>>>
>>> On ARM, the MSI msg (address and data) comes along with
>>> out-of-band device ID information. The device ID encodes the device
>>> that composes the MSI msg. Let's create a new routing entry type,
>>> dubbed KVM_IRQ_ROUTING_EXTENDED_MSI and use the __u32 pad space
>>> to convey the device ID.
>>>
>>> Signed-off-by: Eric Auger <eric.auger@linaro.org>
>>>
>>> ---
>>>
>>> RFC -> PATCH
>>> - remove kvm_irq_routing_extended_msi and use union instead
>>> ---
>>> Documentation/virtual/kvm/api.txt | 9 ++++++++-
>>> include/uapi/linux/kvm.h | 6 +++++-
>>> 2 files changed, 13 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
>>> index d20fd94..6426ae9 100644
>>> --- a/Documentation/virtual/kvm/api.txt
>>> +++ b/Documentation/virtual/kvm/api.txt
>>> @@ -1414,7 +1414,10 @@ struct kvm_irq_routing_entry {
>>> __u32 gsi;
>>> __u32 type;
>>> __u32 flags;
>>> - __u32 pad;
>>> + union {
>>> + __u32 pad;
>>> + __u32 devid;
>>> + };
>>> union {
>>> struct kvm_irq_routing_irqchip irqchip;
>>> struct kvm_irq_routing_msi msi;
>>
>> devid is actually a part of MSI bunch. Shouldn't it be a part of struct kvm_irq_routing_msi then?
>> It also has reserved pad.
>>
>>> @@ -1427,6 +1430,10 @@ struct kvm_irq_routing_entry {
>>> #define KVM_IRQ_ROUTING_IRQCHIP 1
>>> #define KVM_IRQ_ROUTING_MSI 2
>>> #define KVM_IRQ_ROUTING_S390_ADAPTER 3
>>> +#define KVM_IRQ_ROUTING_EXTENDED_MSI 4
>>> +
>>> +In case of KVM_IRQ_ROUTING_EXTENDED_MSI routing type, devid is used to convey
>>> +the device ID.
>>>
>>> No flags are specified so far, the corresponding field must be set to zero.
>>
>> What if we use KVM_MSI_VALID_DEVID flag instead of new KVM_IRQ_ROUTING_EXTENDED_MSI definition? I
>> believe this would make an API more consistent and introduce less new definitions.
>
> I like this approach, but it runs into problems:
> As you read above the current documentation says that the flags field
> must be zero and the current KVM_SET_GSI_ROUTING handler bails out if it
> isn't. So userland would need to know whether it's safe to set that
> field. Introducing a new KVM_CAP_... value seems overkill if we could
> just have a new routing entry type. So we could still reuse the existing
> struct kvm_irq_routing_msi (and extend that with the devid field), but
> we would have to add a new routing type number.
> Maybe we could collapse this into the existing MSI type + flag when
> handing it further down the kernel?
FWIW, I gave this a try, this doesn't look to bad. I carried the new
type down till virt/kvm/arm/vgic.c:kvm_set_routing_entry(), where the
EXTENDED type got turned back into the normal MSI type while setting the
flag in the internal struct kvm_kernel_irq_routing_entry. This keeps the
new type only to the userland facing side, with the kernel code staying
mostly the same.
Together with a new KVM_CAP_MSIS_REQUIRE_DEVID capability I can now
drive both GICv2M and ITS emulation from the same userland base in a
sane manner.
If someone wants to have a look now, tell me, otherwise I will wait for
Eric's upcoming code drop and comment on that then.
Cheers,
Andre.
>
> Cheers,
> Andre.
>
>>
>>>
>>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
>>> index 2a23705..8484681 100644
>>> --- a/include/uapi/linux/kvm.h
>>> +++ b/include/uapi/linux/kvm.h
>>> @@ -841,12 +841,16 @@ struct kvm_irq_routing_s390_adapter {
>>> #define KVM_IRQ_ROUTING_IRQCHIP 1
>>> #define KVM_IRQ_ROUTING_MSI 2
>>> #define KVM_IRQ_ROUTING_S390_ADAPTER 3
>>> +#define KVM_IRQ_ROUTING_EXTENDED_MSI 4
>>>
>>> struct kvm_irq_routing_entry {
>>> __u32 gsi;
>>> __u32 type;
>>> __u32 flags;
>>> - __u32 pad;
>>> + union {
>>> + __u32 pad;
>>> + __u32 devid;
>>> + };
>>> union {
>>> struct kvm_irq_routing_irqchip irqchip;
>>> struct kvm_irq_routing_msi msi;
>>> --
>>> 1.9.1
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>>> the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>> Kind regards,
>> Pavel Fedin
>> Expert Engineer
>> Samsung Electronics Research center Russia
>>
WARNING: multiple messages have this Message-ID (diff)
From: Andre Przywara <andre.przywara@arm.com>
To: Pavel Fedin <p.fedin@samsung.com>,
"'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>,
"christoffer.dall@linaro.org" <christoffer.dall@linaro.org>,
"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>
Subject: Re: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi
Date: Fri, 3 Jul 2015 16:53:50 +0100 [thread overview]
Message-ID: <5596B00E.2020706@arm.com> (raw)
In-Reply-To: <5596503E.6040902@arm.com>
Hi,
On 03/07/15 10:05, Andre Przywara wrote:
> Hi Pavel,
>
> On 02/07/15 08:26, Pavel Fedin wrote:
>> Hello!
>>
>>> -----Original Message-----
>>> From: kvm-owner@vger.kernel.org [mailto:kvm-owner@vger.kernel.org] On Behalf Of Eric Auger
>>> Sent: Monday, June 29, 2015 6:37 PM
>>> To: eric.auger@st.com; eric.auger@linaro.org; linux-arm-kernel@lists.infradead.org;
>>> marc.zyngier@arm.com; christoffer.dall@linaro.org; andre.przywara@arm.com;
>>> kvmarm@lists.cs.columbia.edu; kvm@vger.kernel.org
>>> Cc: linux-kernel@vger.kernel.org; patches@linaro.org; p.fedin@samsung.com; pbonzini@redhat.com
>>> Subject: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi
>>>
>>> On ARM, the MSI msg (address and data) comes along with
>>> out-of-band device ID information. The device ID encodes the device
>>> that composes the MSI msg. Let's create a new routing entry type,
>>> dubbed KVM_IRQ_ROUTING_EXTENDED_MSI and use the __u32 pad space
>>> to convey the device ID.
>>>
>>> Signed-off-by: Eric Auger <eric.auger@linaro.org>
>>>
>>> ---
>>>
>>> RFC -> PATCH
>>> - remove kvm_irq_routing_extended_msi and use union instead
>>> ---
>>> Documentation/virtual/kvm/api.txt | 9 ++++++++-
>>> include/uapi/linux/kvm.h | 6 +++++-
>>> 2 files changed, 13 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
>>> index d20fd94..6426ae9 100644
>>> --- a/Documentation/virtual/kvm/api.txt
>>> +++ b/Documentation/virtual/kvm/api.txt
>>> @@ -1414,7 +1414,10 @@ struct kvm_irq_routing_entry {
>>> __u32 gsi;
>>> __u32 type;
>>> __u32 flags;
>>> - __u32 pad;
>>> + union {
>>> + __u32 pad;
>>> + __u32 devid;
>>> + };
>>> union {
>>> struct kvm_irq_routing_irqchip irqchip;
>>> struct kvm_irq_routing_msi msi;
>>
>> devid is actually a part of MSI bunch. Shouldn't it be a part of struct kvm_irq_routing_msi then?
>> It also has reserved pad.
>>
>>> @@ -1427,6 +1430,10 @@ struct kvm_irq_routing_entry {
>>> #define KVM_IRQ_ROUTING_IRQCHIP 1
>>> #define KVM_IRQ_ROUTING_MSI 2
>>> #define KVM_IRQ_ROUTING_S390_ADAPTER 3
>>> +#define KVM_IRQ_ROUTING_EXTENDED_MSI 4
>>> +
>>> +In case of KVM_IRQ_ROUTING_EXTENDED_MSI routing type, devid is used to convey
>>> +the device ID.
>>>
>>> No flags are specified so far, the corresponding field must be set to zero.
>>
>> What if we use KVM_MSI_VALID_DEVID flag instead of new KVM_IRQ_ROUTING_EXTENDED_MSI definition? I
>> believe this would make an API more consistent and introduce less new definitions.
>
> I like this approach, but it runs into problems:
> As you read above the current documentation says that the flags field
> must be zero and the current KVM_SET_GSI_ROUTING handler bails out if it
> isn't. So userland would need to know whether it's safe to set that
> field. Introducing a new KVM_CAP_... value seems overkill if we could
> just have a new routing entry type. So we could still reuse the existing
> struct kvm_irq_routing_msi (and extend that with the devid field), but
> we would have to add a new routing type number.
> Maybe we could collapse this into the existing MSI type + flag when
> handing it further down the kernel?
FWIW, I gave this a try, this doesn't look to bad. I carried the new
type down till virt/kvm/arm/vgic.c:kvm_set_routing_entry(), where the
EXTENDED type got turned back into the normal MSI type while setting the
flag in the internal struct kvm_kernel_irq_routing_entry. This keeps the
new type only to the userland facing side, with the kernel code staying
mostly the same.
Together with a new KVM_CAP_MSIS_REQUIRE_DEVID capability I can now
drive both GICv2M and ITS emulation from the same userland base in a
sane manner.
If someone wants to have a look now, tell me, otherwise I will wait for
Eric's upcoming code drop and comment on that then.
Cheers,
Andre.
>
> Cheers,
> Andre.
>
>>
>>>
>>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
>>> index 2a23705..8484681 100644
>>> --- a/include/uapi/linux/kvm.h
>>> +++ b/include/uapi/linux/kvm.h
>>> @@ -841,12 +841,16 @@ struct kvm_irq_routing_s390_adapter {
>>> #define KVM_IRQ_ROUTING_IRQCHIP 1
>>> #define KVM_IRQ_ROUTING_MSI 2
>>> #define KVM_IRQ_ROUTING_S390_ADAPTER 3
>>> +#define KVM_IRQ_ROUTING_EXTENDED_MSI 4
>>>
>>> struct kvm_irq_routing_entry {
>>> __u32 gsi;
>>> __u32 type;
>>> __u32 flags;
>>> - __u32 pad;
>>> + union {
>>> + __u32 pad;
>>> + __u32 devid;
>>> + };
>>> union {
>>> struct kvm_irq_routing_irqchip irqchip;
>>> struct kvm_irq_routing_msi msi;
>>> --
>>> 1.9.1
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>> Kind regards,
>> Pavel Fedin
>> Expert Engineer
>> Samsung Electronics Research center Russia
>>
next prev parent reply other threads:[~2015-07-03 15:42 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 [this message]
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
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=5596B00E.2020706@arm.com \
--to=andre.przywara@arm.com \
--cc=Marc.Zyngier@arm.com \
--cc=christoffer.dall@linaro.org \
--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=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.