On Tue, 3 Mar 2015, Stefano Stabellini wrote:
> On Mon, 2 Mar 2015, vijay.kil...@gmail.com wrote:
> > @@ -94,19 +95,29 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu
> > *v, mmio_info_t *info,
> > switch ( gicr_reg )
> > {
> > case GICR_CTLR:
> > - /* We have not implemented LPI's, read zero */
> > - goto read_as_zero;
> > + /*
> > + * Enable LPI's for ITS. Direct injection of LPI
> > + * by writing to GICR_{SET,CLR}LPIR are not supported
> > + */
>
> Is this actually a limitation that we can have? Is there a way to
> communicate to the guest OS that GICR_{SET,CLR}LPIR are not supported?
Actually the GICv3 spec says:
Note: this register is mandatory in an implementation that supports LPIs
and does not include an ITS. The register location is IMPLEMENTATION
DEFINED in an implementation that does include an ITS.
So, if we include the vITS, does this mean that we can simply make this
register disappear?
>
> > + if ( dabt.size != DABT_WORD ) goto bad_width;
> > + vgic_lock(v);
> > + *r = v->domain->arch.vgic.gicr_ctlr;
> > + vgic_unlock(v);
> > + return 1;
> > case GICR_IIDR:
> > if ( dabt.size != DABT_WORD ) goto bad_width;
> > *r = GICV3_GICR_IIDR_VAL;
> > return 1;
> > case GICR_TYPER:
> > - if ( dabt.size != DABT_DOUBLE_WORD ) goto bad_width;
> > - /* TBD: Update processor id in [23:8] when ITS support is added */
> > + if ( dabt.size != DABT_WORD && dabt.size != DABT_DOUBLE_WORD )
> > + goto bad_width;
> > + /* XXX: Update processor id in [23:8] if GITS_TYPER: PTA is not
> > set */
> > aff = (MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 3) << 56 |
> > MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 2) << 48 |
> > MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 1) << 40 |
> > MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 0) << 32);
> > + /* Set LPI support */
> > + aff |= (GICR_TYPER_DISTRIBUTED_IMP | GICR_TYPER_PLPIS);
> > *r = aff;
> > return 1;
> > case GICR_STATUSR:
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
