Re: [Xen-devel] [PATCH V6 01/10] xen/arm: gic-v3: Increase the size of GICR in address space for guest

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 05/06/2015 17:31, Ian Campbell wrote:
> On Fri, 2015-06-05 at 17:04 +0100, Julien Grall wrote:
> > On 05/06/15 16:49, Ian Campbell wrote:
> > > On Mon, 2015-06-01 at 20:56 +0800, Chen Baozi wrote:
> > > > From: Chen Baozi <baozich@xxxxxxxxx>
> > > >
> > > > Currently it only supports up to 8 vCPUs. Increase the region to hold
> > > > up to 128 vCPUs, which is the maximum number that GIC-500 supports.
> > > >
> > > > Signed-off-by: Chen Baozi <baozich@xxxxxxxxx>
> > > > Reviewed-by: Julien Grall <julien.grall@xxxxxxxxxx>
> > > Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> > >
> > > I did briefly wonder if we should shoot for the stars here and reserve
> > > space for some enormous set of processors, but I suppose there's no
> > > need.
> > I though about the same things. AFF0 + AFF1 gives 4096 CPUs.
> >
> > Although as we will support only 128 vCPUs (see the last patch),
> > reserving more space is not necessary. This space saved can be used for
> > a bigger PCI MMIO region later.
> I don't think rdistr regions need to be contiguous, so we could consider
> (not now, when it happens) putting CPUs 128+ into the gap above 4G, on
> the basis that a guest with that many CPUs is almost certainly going to
> have tonnes of RAM and therefore be 64 bit...
Right, the vGICv3 is supporting multiple rdist regions.

FWIW, we don't need to make any assumption as the vGICv3 driver is only 
for 64 bits guests. The emulation misses some bits for a full support of 
32 bit domain (such splitting register access and cp regs).
That made me think that I'm allowing a 32 bits domain to be boot with a 
vGICv3. I may want to disable this possibility for now.
Regards,

--
Julien Grall

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