From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: [PATCH v2 02/27] ARM: GICv3: allocate LPI pending and property table Date: Tue, 21 Mar 2017 16:27:58 -0700 (PDT) Message-ID: References: <20170316112030.20419-1-andre.przywara@arm.com> <20170316112030.20419-3-andre.przywara@arm.com> Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1594849134-1490138879=:11679" Return-path: Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cqTC8-0005N6-NH for xen-devel@lists.xenproject.org; Tue, 21 Mar 2017 23:28:04 +0000 In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: =?UTF-8?Q?Andr=C3=A9_Przywara?= Cc: xen-devel@lists.xenproject.org, Julien Grall , Stefano Stabellini , Shanker Donthineni , Vijay Kilari List-Id: xen-devel@lists.xenproject.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1594849134-1490138879=:11679 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Tue, 21 Mar 2017, André Przywara wrote: > On 21/03/17 22:57, Stefano Stabellini wrote: > > On Thu, 16 Mar 2017, Andre Przywara wrote: > >> The ARM GICv3 provides a new kind of interrupt called LPIs. > >> The pending bits and the configuration data (priority, enable bits) for > >> those LPIs are stored in tables in normal memory, which software has to > >> provide to the hardware. > >> Allocate the required memory, initialize it and hand it over to each > >> redistributor. The maximum number of LPIs to be used can be adjusted with > >> the command line option "max_lpi_bits", which defaults to a compile time > >> constant exposed in Kconfig. > >> > >> Signed-off-by: Andre Przywara > > .... > > >> diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c > >> new file mode 100644 > >> index 0000000..4f8414b > >> --- /dev/null > >> +++ b/xen/arch/arm/gic-v3-lpi.c > > .... > > >> +/* > >> + * Tell a redistributor about the (shared) property table, allocating one > >> + * if not already done. > >> + */ > >> +static int gicv3_lpi_set_proptable(void __iomem * rdist_base) > >> +{ > >> + uint64_t reg; > >> + > >> + reg = GIC_BASER_CACHE_RaWaWb << GICR_PROPBASER_INNER_CACHEABILITY_SHIFT; > >> + reg |= GIC_BASER_CACHE_SameAsInner << GICR_PROPBASER_OUTER_CACHEABILITY_SHIFT; > >> + reg |= GIC_BASER_InnerShareable << GICR_PROPBASER_SHAREABILITY_SHIFT; > >> + > >> + /* > >> + * The property table is shared across all redistributors, so allocate > >> + * this only once, but return the same value on subsequent calls. > >> + */ > >> + if ( !lpi_data.lpi_property ) > >> + { > >> + /* The property table holds one byte per LPI. */ > >> + unsigned int order = get_order_from_bytes(lpi_data.nr_host_lpis); > >> + void *table = alloc_xenheap_pages(order, 0); > > > > you investigated the possibility of using _xmalloc to 64K align it? > > Yes, _xmalloc gives me the alignment, but AFAICT not the physical > contiguous memory guarantee the table needs. If there are other ways to > satisfy those requirements, I am all ears. Otherwise I'd just add a > comment to motivate this. OK, but the problem is that I am not sure whether alloc_xenheap_pages makes any guarantees on the alignment of the allocated pages. Is it possible to allocate 1<<4 pages that are not 64K aligned with it? --8323329-1594849134-1490138879=:11679 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --8323329-1594849134-1490138879=:11679--