[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v7 1/5] xen/arm: Add support for GIC v3
On Tue, 2014-07-22 at 12:15 +0100, Julien Grall wrote: > > On 22/07/14 12:12, Vijay Kilari wrote: > > On Tue, Jul 22, 2014 at 4:25 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> > > wrote: > >> On Tue, 2014-07-22 at 16:19 +0530, Vijay Kilari wrote: > >>>> > >>>>>>> + * Additional registers defined in GIC v3. > >>>>>>> + * Common GICD registers are defined in gic.h > >>>>>>> + */ > >>>>>>> + > >>>>>>> +#define GICD_STATUSR (0x010) > >>>>>>> [...][ > >>>>>>> +#define GICV3_GICD_PIDR0 (0x92) > >>>>>> > >>>>>> What is the distinction between variables with GIC[DR]_ prefixes and > >>>>>> those with GICV3_GIC[DR]_ ones? > >>>>> > >>>>> GICV3 is prefixed for indicating that there are values not the > >>>>> addresses. > >>>>> In anycase I will remove GICV3 prefixes and postfix _VAL > >>>> > >>>> You mean the value used when emulating a read, I think? > >>> > >>> Yes, it is used in gicv3 driver for checking presence of > >>> re-distributor > >> > >> In the phsyical h/w? That sounds wrong. 0x92 is just one possible value > >> of this register (and the spec says it should be 0x94...). I don't see > >> you using this #define in that way anywhere though so perhaps I've > >> misunderstood. > > > > I am using 20.0 version. which specifies 0x92 for ARM implementations of > > GICv3. > > May be other vendors can use different value. So it is better propagate hw > > value > > for emulation > > > > GICD_PIDR0: > > Bits [7:0]. Bits [7:0] of the ARM-defined DevID field. This field is 0x92 > > in > > ARM implementations of a GICv3 or later Distributor. > > > > In any case, GICD_PIDR0 is not used by gicv3 driver. GICD_PIDR2 & > > GICR_PIDR2 are > > used where check is made on ARCH_REV [7:4] > > > >> > >>> and also in vgicv3 for emulating read. > >> > >> I wonder if we should instead propagate the underlying hardware value? > > > > Yes,we can propagate hardware value. > > I don't think we should propagate the hardware value. We may emulate a > different distributor than the hardware one. In this case, > implementation defined register won't work as expected by the kernel. Then we need to either get our own ID assigned (hard, I expect) or commit to emulating whichever hardware we choose to expose. I don't think emulating the ARM h/w would be a bad choice. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |