[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC PATCH 03/24] ARM: GICv3 ITS: allocate device and collection table



Hi Stefano,

On 26/10/2016 23:57, Stefano Stabellini wrote:
+    int pagesz;
+    int order;
+    void *buffer = NULL;
+
+    attr  = GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
+    attr |= GIC_BASER_CACHE_SameAsInner << GITS_BASER_OUTER_CACHEABILITY_SHIFT;
+    attr |= GIC_BASER_CACHE_RaWaWb << GITS_BASER_INNER_CACHEABILITY_SHIFT;
+
+    /*
+     * Loop over the page sizes (4K, 16K, 64K) to find out what the host
+     * supports.
+     */

Is this really the best way to do it? Can't we assume ITS supports 4K,
given that Xen requires 4K pages at the moment? Is it actually possible
to find hardware that supports 4K but with an ITS that only support 64K
or 16K pages? It seems insane to me. Otherwise can't we probe the page
size somehow?

By reading the spec (8.19.1 in IHI 0069C):

"If the GIC implementation supports only a single, fixed page size, this field might be RO. When this register has an architecturally-defined reset value, if this field is implemented as an RW
field, it resets to a value that is architecturally UNKNOWN."

As the reset value is architecturally unknown the only way to find out the correct page size is to try them one by one.

The GIC is a separate component of the platform and will be programed using physical address (and not virtual one). It would be fine to have a BASE registers supporting only 64K to save few lines in the GIC.

Regards,

--
Julien Grall

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.