On 4 September 2015 at 15:18, Pavel Fedin <p.fe...@samsung.com> wrote: > Hello! > >> I think we need to leave enough space for all of GICC/GICV/GICH >> (that's 2 pages for GICC, 2 for GICV, 1 for GICH). They're optional >> in a GICv3, but we may want them for emulation later on and if we >> haven't left ourselves enough space we'll be a bit stuck. > > Do we really need this? Are we going to have a model with HYP mode, > inside of which we could run another model? BTW, our GICv2 > implementation also doesn't assume that it can have GICV/GICH.
Yes, I think that implementation of Hyp mode is very likely in the future -- Xilinx want it, for instance. > Additionally, according to GIC-500 arch manual, GICC_DIR with > affinity routing enabled has an offset of 0x10000, and it's 17 > pages instead of 2. A register at offset 0x10000 means 2 64K pages, doesn't it? Can you give a more exact reference to the bit of the manual you mean? > Do we want to waste our precious address space? > But, well, i have calculated that we would have 124 maximum CPUs > instead of 126. So - your final word on this? Two fewer CPUs is not a big deal: anybody who finds 124 CPUs a restrictive limit would probably also find 126 CPUs too few. We can just add support for split redistributor ranges in KVM before we get to the point where it's a problem. thanks -- PMM
