Re: [PATCH v2 09/27] ARM: GICv3: introduce separate pending_irq structs for LPIs

From: Julien Grall <julien.grall@arm.com>
To: "André Przywara" <andre.przywara@arm.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org,
	Shanker Donthineni <shankerd@codeaurora.org>,
	Vijay Kilari <vijay.kilari@gmail.com>
Subject: Re: [PATCH v2 09/27] ARM: GICv3: introduce separate pending_irq structs for LPIs
Date: Fri, 24 Mar 2017 10:59:18 +0000	[thread overview]
Message-ID: <4e6e5f99-778b-4f84-1806-3beca7672184@arm.com> (raw)
In-Reply-To: <04f56594-82ff-2c80-96b7-0a49d0af0baf@arm.com>

Hi Andre,

On 03/23/2017 08:08 PM, André Przywara wrote:
> On 22/03/17 23:44, Stefano Stabellini wrote:
>> On Thu, 16 Mar 2017, Andre Przywara wrote:
>>> For the same reason that allocating a struct irq_desc for each
>>> possible LPI is not an option, having a struct pending_irq for each LPI
>>> is also not feasible. However we actually only need those when an
>>> interrupt is on a vCPU (or is about to be injected).
>>> Maintain a list of those structs that we can use for the lifecycle of
>>> a guest LPI. We allocate new entries if necessary, however reuse
>>> pre-owned entries whenever possible.
>>> I added some locking around this list here, however my gut feeling is
>>> that we don't need one because this a per-VCPU structure anyway.
>>> If someone could confirm this, I'd be grateful.
>>> Teach the existing VGIC functions to find the right pointer when being
>>> given a virtual LPI number.
>>>
>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>
>> Still all past comments are unaddress ;-(
>
> Sorry for that. I just see that the reviews for those and later emails
> were not in the same thread as the other ones, so they were swamped in
> my inbox and didn't show up in my TODO thread. This might be due to
> races between direct email and list bounces. Interestingly this seems to
> affect previous emails as well, which isn't really an excuse, but
> explains my perceived rudeness in not addressing your comments (simply
> because I didn't see them).
> I will try to sort this mess out in the next few days and send a new
> version early next week.
> If you know from the top of your head any serious architectural change
> requests you raised, it would be nice if you could repeat them now, so
> that I can address them early enough.

I am planning to have a look at the full series today. And will try to 
point out major architectural changes.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel