From: eric.auger@linaro.org (Eric Auger)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 09/13] KVM: arm64: handle pending bit for LPIs in ITS emulation
Date: Thu, 11 Jun 2015 20:24:14 +0200 [thread overview]
Message-ID: <5579D24E.50208@linaro.org> (raw)
In-Reply-To: <5579B0EA.1090701@arm.com>
On 06/11/2015 06:01 PM, Marc Zyngier wrote:
> On 11/06/15 16:46, Andre Przywara wrote:
>> Salut Eric,
>>
>> On 06/09/2015 04:59 PM, Eric Auger wrote:
>>> On 05/29/2015 11:53 AM, Andre Przywara wrote:
>>>> As the actual LPI number in a guest can be quite high, but is mostly
>>>> assigned using a very sparse allocation scheme, bitmaps and arrays
>>>> for storing the virtual interrupt status are a waste of memory.
>>>> We use our equivalent of the "Interrupt Translation Table Entry"
>>>> (ITTE) to hold this extra status information for a virtual LPI.
>>>> As the normal VGIC code cannot use it's fancy bitmaps to manage
>>>> pending interrupts, we provide a hook in the VGIC code to let the
>>>> ITS emulation handle the list register queueing itself.
>>>> LPIs are located in a separate number range (>=8192), so
>>>> distinguishing them is easy. With LPIs being only edge-triggered, we
>>>> get away with a less complex IRQ handling.
>>>>
>>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>>> ---
>>>> include/kvm/arm_vgic.h | 2 ++
>>>> virt/kvm/arm/its-emul.c | 66 +++++++++++++++++++++++++++++++++++++++++++
>>>> virt/kvm/arm/its-emul.h | 3 ++
>>>> virt/kvm/arm/vgic-v3-emul.c | 2 ++
>>>> virt/kvm/arm/vgic.c | 68 +++++++++++++++++++++++++++++++++------------
>>>> 5 files changed, 124 insertions(+), 17 deletions(-)
>>>>
>>>> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
>>>> index fa17df6..de19c34 100644
>>>> --- a/include/kvm/arm_vgic.h
>>>> +++ b/include/kvm/arm_vgic.h
>>>> @@ -147,6 +147,8 @@ struct vgic_vm_ops {
>>>> int (*init_model)(struct kvm *);
>>>> void (*destroy_model)(struct kvm *);
>>>> int (*map_resources)(struct kvm *, const struct vgic_params *);
>>>> + bool (*queue_lpis)(struct kvm_vcpu *);
>>>> + void (*unqueue_lpi)(struct kvm_vcpu *, int irq);
>>>> };
>>>>
>>>> struct vgic_io_device {
>>>> diff --git a/virt/kvm/arm/its-emul.c b/virt/kvm/arm/its-emul.c
>>>> index f0f4a9c..f75fb9e 100644
>>>> --- a/virt/kvm/arm/its-emul.c
>>>> +++ b/virt/kvm/arm/its-emul.c
>>>> @@ -50,8 +50,26 @@ struct its_itte {
>>>> struct its_collection *collection;
>>>> u32 lpi;
>>>> u32 event_id;
>>>> + bool enabled;
>>>> + unsigned long *pending;
>>> allocated in later patch. does not ease the review of the life cycle but
>>> I guess it is accepted/acceptable.
>>
>> I tried to move some bits around a bit and ran into several issues, so I
>> guess we have to live with that.
>>
>>> Isn't it somehow redundant to have a bitmap here where the collection
>>> already indicates the target cpu id on which the LPI is pending?
>>
>> Unfortunately only "somewhat", as Marc taught me the other day ;-)
>> First, the spec shows that the pending bitmap is allocated _per CPU_, so
>> we have to model this here appropriately.
>> Second, you could have an LPI pending on one distributor, then change
>> the associated collection to another distributor and trigger that
>> interrupt again. This would make it pending on two VCPUs.
>> Admittedly not the most prominent use case, but possible.
>
> The exact scenario is related to the MOVI command, which changes the
> affinity of the interrupt and also move any pending state from another
> CPU. There is no guarantee that these two actions are completed
> atomically w.r.t the delivery of interrupts to CPUs.
>
> We *could* make it atomic, but that would be quite heavy handed.
OK thanks,
The ITS command chapter is my next one ;-)
Best Regards
Eric
>
> M.
>
WARNING: multiple messages have this Message-ID (diff)
From: Eric Auger <eric.auger@linaro.org>
To: Marc Zyngier <marc.zyngier@arm.com>,
Andre Przywara <andre.przywara@arm.com>
Cc: "christoffer.dall@linaro.org" <christoffer.dall@linaro.org>,
"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [PATCH 09/13] KVM: arm64: handle pending bit for LPIs in ITS emulation
Date: Thu, 11 Jun 2015 20:24:14 +0200 [thread overview]
Message-ID: <5579D24E.50208@linaro.org> (raw)
In-Reply-To: <5579B0EA.1090701@arm.com>
On 06/11/2015 06:01 PM, Marc Zyngier wrote:
> On 11/06/15 16:46, Andre Przywara wrote:
>> Salut Eric,
>>
>> On 06/09/2015 04:59 PM, Eric Auger wrote:
>>> On 05/29/2015 11:53 AM, Andre Przywara wrote:
>>>> As the actual LPI number in a guest can be quite high, but is mostly
>>>> assigned using a very sparse allocation scheme, bitmaps and arrays
>>>> for storing the virtual interrupt status are a waste of memory.
>>>> We use our equivalent of the "Interrupt Translation Table Entry"
>>>> (ITTE) to hold this extra status information for a virtual LPI.
>>>> As the normal VGIC code cannot use it's fancy bitmaps to manage
>>>> pending interrupts, we provide a hook in the VGIC code to let the
>>>> ITS emulation handle the list register queueing itself.
>>>> LPIs are located in a separate number range (>=8192), so
>>>> distinguishing them is easy. With LPIs being only edge-triggered, we
>>>> get away with a less complex IRQ handling.
>>>>
>>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>>> ---
>>>> include/kvm/arm_vgic.h | 2 ++
>>>> virt/kvm/arm/its-emul.c | 66 +++++++++++++++++++++++++++++++++++++++++++
>>>> virt/kvm/arm/its-emul.h | 3 ++
>>>> virt/kvm/arm/vgic-v3-emul.c | 2 ++
>>>> virt/kvm/arm/vgic.c | 68 +++++++++++++++++++++++++++++++++------------
>>>> 5 files changed, 124 insertions(+), 17 deletions(-)
>>>>
>>>> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
>>>> index fa17df6..de19c34 100644
>>>> --- a/include/kvm/arm_vgic.h
>>>> +++ b/include/kvm/arm_vgic.h
>>>> @@ -147,6 +147,8 @@ struct vgic_vm_ops {
>>>> int (*init_model)(struct kvm *);
>>>> void (*destroy_model)(struct kvm *);
>>>> int (*map_resources)(struct kvm *, const struct vgic_params *);
>>>> + bool (*queue_lpis)(struct kvm_vcpu *);
>>>> + void (*unqueue_lpi)(struct kvm_vcpu *, int irq);
>>>> };
>>>>
>>>> struct vgic_io_device {
>>>> diff --git a/virt/kvm/arm/its-emul.c b/virt/kvm/arm/its-emul.c
>>>> index f0f4a9c..f75fb9e 100644
>>>> --- a/virt/kvm/arm/its-emul.c
>>>> +++ b/virt/kvm/arm/its-emul.c
>>>> @@ -50,8 +50,26 @@ struct its_itte {
>>>> struct its_collection *collection;
>>>> u32 lpi;
>>>> u32 event_id;
>>>> + bool enabled;
>>>> + unsigned long *pending;
>>> allocated in later patch. does not ease the review of the life cycle but
>>> I guess it is accepted/acceptable.
>>
>> I tried to move some bits around a bit and ran into several issues, so I
>> guess we have to live with that.
>>
>>> Isn't it somehow redundant to have a bitmap here where the collection
>>> already indicates the target cpu id on which the LPI is pending?
>>
>> Unfortunately only "somewhat", as Marc taught me the other day ;-)
>> First, the spec shows that the pending bitmap is allocated _per CPU_, so
>> we have to model this here appropriately.
>> Second, you could have an LPI pending on one distributor, then change
>> the associated collection to another distributor and trigger that
>> interrupt again. This would make it pending on two VCPUs.
>> Admittedly not the most prominent use case, but possible.
>
> The exact scenario is related to the MOVI command, which changes the
> affinity of the interrupt and also move any pending state from another
> CPU. There is no guarantee that these two actions are completed
> atomically w.r.t the delivery of interrupts to CPUs.
>
> We *could* make it atomic, but that would be quite heavy handed.
OK thanks,
The ITS command chapter is my next one ;-)
Best Regards
Eric
>
> M.
>
next prev parent reply other threads:[~2015-06-11 18:24 UTC|newest]
Thread overview: 104+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-29 9:53 [PATCH 00/13] arm64: KVM: GICv3 ITS emulation Andre Przywara
2015-05-29 9:53 ` Andre Przywara
2015-05-29 9:53 ` [PATCH 01/13] KVM: arm/arm64: VGIC: don't track used LRs in the distributor Andre Przywara
2015-05-29 9:53 ` Andre Przywara
2015-06-12 17:23 ` Eric Auger
2015-05-29 9:53 ` [PATCH 02/13] KVM: extend struct kvm_msi to hold a 32-bit device ID Andre Przywara
2015-05-29 9:53 ` Andre Przywara
2015-06-09 8:49 ` Eric Auger
2015-06-09 8:49 ` Eric Auger
2015-06-28 19:12 ` Christoffer Dall
2015-06-28 19:12 ` Christoffer Dall
2015-06-29 14:53 ` Andre Przywara
2015-06-29 14:53 ` Andre Przywara
2015-06-29 15:02 ` Christoffer Dall
2015-06-29 15:02 ` Christoffer Dall
2015-05-29 9:53 ` [PATCH 03/13] KVM: arm/arm64: add emulation model specific destroy function Andre Przywara
2015-05-29 9:53 ` Andre Przywara
2015-06-09 8:51 ` Eric Auger
2015-06-09 8:51 ` Eric Auger
2015-06-28 19:14 ` Christoffer Dall
2015-06-28 19:14 ` Christoffer Dall
2015-05-29 9:53 ` [PATCH 04/13] KVM: arm64: Introduce new MMIO region for the ITS base address Andre Przywara
2015-05-29 9:53 ` Andre Przywara
2015-06-09 8:52 ` Eric Auger
2015-06-09 8:52 ` Eric Auger
2015-06-11 15:12 ` Andre Przywara
2015-06-11 15:12 ` Andre Przywara
2015-05-29 9:53 ` [PATCH 05/13] KVM: arm64: handle ITS related GICv3 redistributor registers Andre Przywara
2015-05-29 9:53 ` Andre Przywara
2015-06-09 8:52 ` Eric Auger
2015-06-09 8:52 ` Eric Auger
2015-06-12 17:03 ` Andre Przywara
2015-06-12 17:03 ` Andre Przywara
2015-05-29 9:53 ` [PATCH 06/13] KVM: arm64: introduce ITS emulation file with stub functions Andre Przywara
2015-05-29 9:53 ` Andre Przywara
2015-06-09 9:23 ` Eric Auger
2015-06-09 9:23 ` Eric Auger
2015-05-29 9:53 ` [PATCH 07/13] KVM: arm64: implement basic ITS register handlers Andre Przywara
2015-05-29 9:53 ` Andre Przywara
2015-06-09 13:34 ` Eric Auger
2015-06-09 13:34 ` Eric Auger
2015-06-28 19:36 ` Christoffer Dall
2015-06-28 19:36 ` Christoffer Dall
2015-05-29 9:53 ` [PATCH 08/13] KVM: arm64: add data structures to model ITS interrupt translation Andre Przywara
2015-05-29 9:53 ` Andre Przywara
2015-06-09 15:59 ` Eric Auger
2015-06-09 15:59 ` Eric Auger
2015-05-29 9:53 ` [PATCH 09/13] KVM: arm64: handle pending bit for LPIs in ITS emulation Andre Przywara
2015-05-29 9:53 ` Andre Przywara
2015-06-09 15:59 ` Eric Auger
2015-06-09 15:59 ` Eric Auger
2015-06-11 15:46 ` Andre Przywara
2015-06-11 15:46 ` Andre Przywara
2015-06-11 16:01 ` Marc Zyngier
2015-06-11 16:01 ` Marc Zyngier
2015-06-11 18:24 ` Eric Auger [this message]
2015-06-11 18:24 ` Eric Auger
2015-05-29 9:53 ` [PATCH 10/13] KVM: arm64: sync LPI properties and status between guest and KVM Andre Przywara
2015-05-29 9:53 ` Andre Przywara
2015-06-11 17:44 ` Eric Auger
2015-06-11 17:44 ` Eric Auger
2015-06-28 19:33 ` Christoffer Dall
2015-06-28 19:33 ` Christoffer Dall
2015-05-29 9:53 ` [PATCH 11/13] KVM: arm64: implement ITS command queue command handlers Andre Przywara
2015-05-29 9:53 ` Andre Przywara
2015-06-12 15:28 ` Eric Auger
2015-06-12 15:28 ` Eric Auger
2015-06-28 19:41 ` Christoffer Dall
2015-06-28 19:41 ` Christoffer Dall
2015-07-03 15:57 ` Andre Przywara
2015-07-03 15:57 ` Andre Przywara
2015-07-03 21:01 ` Christoffer Dall
2015-07-03 21:01 ` Christoffer Dall
2015-05-29 9:53 ` [PATCH 12/13] KVM: arm64: implement MSI injection in ITS emulation Andre Przywara
2015-05-29 9:53 ` Andre Przywara
2015-06-11 17:43 ` Eric Auger
2015-06-11 17:43 ` Eric Auger
2015-07-06 16:46 ` Andre Przywara
2015-07-06 16:46 ` Andre Przywara
2015-07-07 8:13 ` Christoffer Dall
2015-07-07 8:13 ` Christoffer Dall
2015-05-29 9:53 ` [PATCH 13/13] KVM: arm64: enable ITS emulation as a virtual MSI controller Andre Przywara
2015-05-29 9:53 ` Andre Przywara
2015-06-12 16:05 ` Eric Auger
2015-06-12 16:05 ` Eric Auger
2015-06-18 8:43 ` Eric Auger
2015-06-18 8:43 ` Eric Auger
2015-06-18 14:22 ` Andre Przywara
2015-06-18 14:22 ` Andre Przywara
2015-06-18 15:03 ` Pavel Fedin
2015-06-18 15:03 ` Pavel Fedin
2015-06-18 19:20 ` Andre Przywara
2015-06-18 19:20 ` Andre Przywara
2015-06-08 6:53 ` [PATCH 00/13] arm64: KVM: GICv3 ITS emulation Pavel Fedin
2015-06-08 6:53 ` Pavel Fedin
2015-06-08 8:23 ` Marc Zyngier
2015-06-08 8:23 ` Marc Zyngier
2015-06-08 10:54 ` Pavel Fedin
2015-06-08 10:54 ` Pavel Fedin
2015-06-08 17:13 ` Marc Zyngier
2015-06-08 17:13 ` Marc Zyngier
2015-06-09 8:12 ` Eric Auger
2015-06-09 8:12 ` Eric Auger
2015-06-10 12:18 ` 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=5579D24E.50208@linaro.org \
--to=eric.auger@linaro.org \
--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 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.