linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: eric.auger@linaro.org (Eric Auger)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 10/15] KVM: arm64: add data structures to model ITS interrupt translation
Date: Thu, 27 Aug 2015 16:16:37 +0200	[thread overview]
Message-ID: <55DF1BC5.3020100@linaro.org> (raw)
In-Reply-To: <55DC4E3F.506@arm.com>

Hi Andre,
On 08/25/2015 01:15 PM, Andre Przywara wrote:
> Hi Eric,
> 
> On 13/08/15 16:46, Eric Auger wrote:
>>
>> On 07/10/2015 04:21 PM, Andre Przywara wrote:
>>> The GICv3 Interrupt Translation Service (ITS) uses tables in memory
>>> to allow a sophisticated interrupt routing. It features device tables,
>>> an interrupt table per device and a table connecting "collections" to
>>> actual CPUs (aka. redistributors in the GICv3 lingo).
>>> Since the interrupt numbers for the LPIs are allocated quite sparsely
>>> and the range can be quite huge (8192 LPIs being the minimum), using
>>> bitmaps or arrays for storing information is a waste of memory.
>>> We use linked lists instead, which we iterate linearily. This works
>>> very well with the actual number of LPIs/MSIs in the guest being
>>> quite low. Should the number of LPIs exceed the number where iterating
>>> through lists seems acceptable, we can later revisit this and use more
>>> efficient data structures.
>>>
>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>> ---
>>>  include/kvm/arm_vgic.h  |  3 +++
>>>  virt/kvm/arm/its-emul.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
>>>  2 files changed, 51 insertions(+)
>>>
>>> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
>>> index b432055..1648668 100644
>>> --- a/include/kvm/arm_vgic.h
>>> +++ b/include/kvm/arm_vgic.h
>>> @@ -25,6 +25,7 @@
>>>  #include <linux/spinlock.h>
>>>  #include <linux/types.h>
>>>  #include <kvm/iodev.h>
>>> +#include <linux/list.h>
>>>  
>>>  #define VGIC_NR_IRQS_LEGACY	256
>>>  #define VGIC_NR_SGIS		16
>>> @@ -162,6 +163,8 @@ struct vgic_its {
>>>  	u64			cbaser;
>>>  	int			creadr;
>>>  	int			cwriter;
>>> +	struct list_head	device_list;
>>> +	struct list_head	collection_list;
>>>  };
>>>  
>>>  struct vgic_dist {
>>> diff --git a/virt/kvm/arm/its-emul.c b/virt/kvm/arm/its-emul.c
>>> index b498f06..7f217fa 100644
>>> --- a/virt/kvm/arm/its-emul.c
>>> +++ b/virt/kvm/arm/its-emul.c
>>> @@ -21,6 +21,7 @@
>>>  #include <linux/kvm.h>
>>>  #include <linux/kvm_host.h>
>>>  #include <linux/interrupt.h>
>>> +#include <linux/list.h>
>>>  
>>>  #include <linux/irqchip/arm-gic-v3.h>
>>>  #include <kvm/arm_vgic.h>
>>> @@ -32,6 +33,25 @@
>>>  #include "vgic.h"
>>>  #include "its-emul.h"
>>>  
>>> +struct its_device {
>>> +	struct list_head dev_list;
>>> +	struct list_head itt;
>>> +	u32 device_id;
>>> +};
>>> +
>>> +struct its_collection {
>>> +	struct list_head coll_list;
>>> +	u32 collection_id;
>>> +	u32 target_addr;
>>> +};
>>> +
>>> +struct its_itte {
>>> +	struct list_head itte_list;
>>> +	struct its_collection *collection;
>>> +	u32 lpi;
>>> +	u32 event_id;
>>> +};
>>> +
>>>  #define BASER_BASE_ADDRESS(x) ((x) & 0xfffffffff000ULL)
>>>  
>>>  /* The distributor lock is held by the VGIC MMIO handler. */
>>> @@ -311,6 +331,9 @@ int vits_init(struct kvm *kvm)
>>>  
>>>  	spin_lock_init(&its->lock);
>>>  
>>> +	INIT_LIST_HEAD(&its->device_list);
>>> +	INIT_LIST_HEAD(&its->collection_list);
>>> +
>>>  	its->enabled = false;
>>>  
>>>  	return -ENXIO;
>>> @@ -320,11 +343,36 @@ void vits_destroy(struct kvm *kvm)
>>>  {
>>>  	struct vgic_dist *dist = &kvm->arch.vgic;
>>>  	struct vgic_its *its = &dist->its;
>>> +	struct its_device *dev;
>>> +	struct its_itte *itte;
>>> +	struct list_head *dev_cur, *dev_temp;
>>> +	struct list_head *cur, *temp;
>>>  
>>>  	if (!vgic_has_its(kvm))
>>>  		return;
>>>  
>>> +	if (!its->device_list.next)
>> Why not using list_empty? But I think I would simply remove this since
>> the empty case if handle below...
> 
> list_empty() requires the list to be initialized before. This check here
> is to detect that map_resources was never called (this is only done on
> the first VCPU run) and thus device_list is basically still all zeroes.
> If we abort the guest without ever running a VCPU (for instance because
> some initialization failed), we call vits_destroy() anyway (because this
> is called when tearing down the VGIC device).
> So the check is here to detect early that vits_destroy() has been called
> without the ITS ever been fully initialized. This fixed a real bug when
> the guest start was aborted before the ITS was ever used.
> I will add a comment to make this clear.

OK. My next question is why don't we call vits_init in vgic_init after
dist->nr_cpus? I had in mind map_resources was linked to the setting of
vgic_dist_base & vgic_cpu_base. Here you do not depend on those
addresses? Do I miss smthg?
> 
>>> +		return;
>>> +
>>> +	spin_lock(&its->lock);
>>> +	list_for_each_safe(dev_cur, dev_temp, &its->device_list) {
>>> +		dev = container_of(dev_cur, struct its_device, dev_list);
>> isn't the usage of list_for_each_entry_safe more synthetic here?
Sorry my point was about the _ENTRY_ variant that should avoid to use
container_of, isn't it?

Eric
> 
> If I got this correctly, we need the _safe variant if we want to remove
> the list item within the loop. Or am I missing something here?
> 
> Cheers,
> Andre.
> 
> 
>>> +		list_for_each_safe(cur, temp, &dev->itt) {
>>> +			itte = (container_of(cur, struct its_itte, itte_list));
>> same
>>
>> Eric
>>> +			list_del(cur);
>>> +			kfree(itte);
>>> +		}
>>> +		list_del(dev_cur);
>>> +		kfree(dev);
>>> +	}
>>> +
>>> +	list_for_each_safe(cur, temp, &its->collection_list) {
>>> +		list_del(cur);
>>> +		kfree(container_of(cur, struct its_collection, coll_list));
>>> +	}
>>> +
>>>  	kfree(dist->pendbaser);
>>>  
>>>  	its->enabled = false;
>>> +	spin_unlock(&its->lock);
>>>  }
>>>
>>

  reply	other threads:[~2015-08-27 14:16 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-10 14:21 [PATCH v2 00/15] KVM: arm64: GICv3 ITS emulation Andre Przywara
2015-07-10 14:21 ` [PATCH v2 01/15] KVM: arm/arm64: VGIC: don't track used LRs in the distributor Andre Przywara
2015-08-12  9:01   ` Eric Auger
2015-08-24 16:33     ` Andre Przywara
2015-08-31  8:42       ` Eric Auger
2015-09-02  9:00         ` Andre Przywara
2015-10-02  9:55   ` Pavel Fedin
2015-10-02 10:32     ` Andre Przywara
2015-10-02 10:39       ` Pavel Fedin
2015-10-02 12:39       ` Pavel Fedin
2015-10-02 12:49         ` Andre Przywara
2015-07-10 14:21 ` [PATCH v2 02/15] KVM: extend struct kvm_msi to hold a 32-bit device ID Andre Przywara
2015-07-10 14:21 ` [PATCH v2 03/15] KVM: arm/arm64: add emulation model specific destroy function Andre Przywara
2015-07-10 14:21 ` [PATCH v2 04/15] KVM: arm/arm64: extend arch CAP checks to allow per-VM capabilities Andre Przywara
2015-08-12 12:26   ` Eric Auger
2015-07-10 14:21 ` [PATCH v2 05/15] KVM: arm/arm64: make GIC frame address initialization model specific Andre Przywara
2015-08-12 13:02   ` Eric Auger
2015-08-24 17:24     ` Andre Przywara
2015-08-31  9:31       ` Eric Auger
2015-07-10 14:21 ` [PATCH v2 06/15] KVM: arm64: Introduce new MMIO region for the ITS base address Andre Przywara
2015-08-13 12:17   ` Eric Auger
2015-07-10 14:21 ` [PATCH v2 07/15] KVM: arm64: handle ITS related GICv3 redistributor registers Andre Przywara
2015-08-13 12:17   ` Eric Auger
2015-08-24 18:08     ` Andre Przywara
2015-07-10 14:21 ` [PATCH v2 08/15] KVM: arm64: introduce ITS emulation file with stub functions Andre Przywara
2015-08-13 12:48   ` Eric Auger
2015-08-25  9:39     ` Andre Przywara
2015-07-10 14:21 ` [PATCH v2 09/15] KVM: arm64: implement basic ITS register handlers Andre Przywara
2015-08-13 15:25   ` Eric Auger
2015-08-25 10:23     ` Andre Przywara
2015-10-02  7:51   ` Pavel Fedin
2015-07-10 14:21 ` [PATCH v2 10/15] KVM: arm64: add data structures to model ITS interrupt translation Andre Przywara
2015-08-13 15:46   ` Eric Auger
2015-08-25 11:15     ` Andre Przywara
2015-08-27 14:16       ` Eric Auger [this message]
2015-07-10 14:21 ` [PATCH v2 11/15] KVM: arm64: handle pending bit for LPIs in ITS emulation Andre Przywara
2015-08-14 11:58   ` Eric Auger
2015-08-25 14:34     ` Andre Przywara
2015-08-31  9:45       ` Eric Auger
2015-10-07  8:39   ` Pavel Fedin
2015-10-07 19:53     ` Christoffer Dall
2015-07-10 14:21 ` [PATCH v2 12/15] KVM: arm64: sync LPI configuration and pending tables Andre Przywara
2015-08-14 11:58   ` Eric Auger
2015-08-14 12:35     ` Eric Auger
2015-08-25 15:47       ` Andre Przywara
2015-08-31  9:51         ` Eric Auger
2015-08-25 15:27     ` Andre Przywara
2015-08-31  9:47       ` Eric Auger
2015-07-10 14:21 ` [PATCH v2 13/15] KVM: arm64: implement ITS command queue command handlers Andre Przywara
2015-08-17 13:33   ` Eric Auger
2015-10-07 14:54     ` Andre Przywara
2015-07-10 14:21 ` [PATCH v2 14/15] KVM: arm64: implement MSI injection in ITS emulation Andre Przywara
2015-07-31 13:22   ` Eric Auger
2015-08-02 20:20     ` Andre Przywara
2015-08-03  6:41       ` Pavel Fedin
2015-08-03  9:07         ` Eric Auger
2015-08-03  9:16           ` Pavel Fedin
2015-08-03 15:37             ` Eric Auger
2015-08-03 17:06               ` Marc Zyngier
2015-08-04  6:53                 ` Pavel Fedin
2015-08-24 14:14                 ` Andre Przywara
2015-08-17 13:44   ` Eric Auger
2015-07-10 14:21 ` [PATCH v2 15/15] KVM: arm64: enable ITS emulation as a virtual MSI controller Andre Przywara
2015-07-15  9:10   ` Pavel Fedin
2015-07-15  9:52     ` Andre Przywara
2015-07-15 10:01       ` Pavel Fedin
2015-07-15 12:02 ` [PATCH v2 00/15] KVM: arm64: GICv3 ITS emulation Pavel Fedin
2015-09-24 11:18 ` Pavel Fedin
2015-09-24 11:35   ` Andre Przywara

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=55DF1BC5.3020100@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 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).