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

[Julien Grall <julien.grall@xxxxxxx>]

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