Re: [Xen-devel] [PATCH v2 14/15] xen/arm: Add vgic support for GIC v3

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2014-04-10 at 16:49 +0530, Vijay Kilari wrote:

> I mean, I don't have V2 hardware to test any trivial changes that I do to
> GIC v2. In all my patches, I am not making any changes to functionality of
> v2 except code movement and changing names

I can test it if necessary. Do you have access to fast models or
anything similar?

> >> >> +    case GICR_SETLPIR:
> >> > I think you should either register two mmio handlers or maybe just
> >> > handle this all at once in a single callback.
> >> >
> >>    There is only one address rdistributore base and size extracted from dt.
> >> So we register one handle for this entire region and this single callback 
> >> will
> >> take access either GICR or SGI's GICR region.
> >
> > Having a single region in DT doesn't stop you from doing the same
> > calculation you do now in the callback at init time and registering two
> > regions.
> >
> SGI GICR region is per cpu, there is no single address with which
> we can register a callback. So we register one callback for entire
> re-distributor region and if it falls in that region we consider it
> re-distributor
> access.

Ah ok, that makes sense. Thanks.

> This callback will take re-distributor stride offset and finds offset.
> 
> Also, this reduces the additional check for sgi re-distributor region
> 
> >> > I didn't see any system register handling, I suppose that is all handled
> >> > by the hardware GICV stuff?
> >>    For all system register accesses in Dom's, HW treats are virtual access.
> >> The memory mapped GICD & GICR registers are virtualized by VGIC
> >
> > I was looking for some register configuration which causes EL1 accesses
> > to the system registers to go to the "GICV" equivalent, but I didn't see
> > it. Can you point me to it please?
> >
> You mean ICC_SRE_EL2 register.  GICv3 by default enables SRE bit.

Excellent, thanks.


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