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@lists.xen.org
https://lists.xen.org/xen-devel
