|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 11/17] xen/arm: ITS: Add GICR register emulation
On Fri, 2015-07-10 at 13:12 +0530, vijay.kilari@xxxxxxxxx wrote:
> [...]
> +int vits_unmap_lpi_prop(struct vcpu *v)
Why is this function called "unmap"?
> + /* Register mmio handlers for this region */
> + register_mmio_handler(v->domain, &vgic_gits_lpi_mmio_handler,
> + maddr, lpi_size);
Something, somewhere, must ensure that we never register this MMIO
handler for any guest which does not have a VITS associated with it.
As it stands after this series I believe that means that the GITS_*
register handling, the GITS LPI MMIO region and the GITS_TRANSLATER
mapping should be setup for dom0 if-and-only-if a physical ITS is
present in the system.
In particular they should never, as it stands today, be mapped for a
domU.
I am unable to spot the code which arranges all that. There is some if's
in the GICR_* handlers, but I don't think that covers everything.
Obviously this will change with the addition of PCI passthrough later
on, but that change should be done in that series and not preemptively
here.
> case GICR_IIDR:
> if ( dabt.size != DABT_WORD ) goto bad_width;
> @@ -106,11 +118,16 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu
> *v, mmio_info_t *info,
> MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 2) << 48 |
> MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 1) << 40 |
> MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 0) << 32);
> + if ( gic_lpi_supported() )
> + {
> + /* Set LPI support */
> + aff |= GICR_TYPER_PLPIS;
> + /* GITS_TYPER.PTA is 0. Provice vcpu number as ta */
"Provide" and an extra space before "0".
> + aff |= (v->vcpu_id << GICR_TYPER_PROCESSOR_SHIFT);
> + }
> *r = aff;
> -
> if ( v->arch.vgic.flags & VGIC_V3_RDIST_LAST )
> *r |= GICR_TYPER_LAST;
> -
Spurious whitespace changes.
> return 1;
> case GICR_STATUSR:
> /* Not implemented */
> @@ -125,10 +142,21 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu
> *v, mmio_info_t *info,
> /* WO. Read as zero */
> goto read_as_zero_64;
> case GICR_PROPBASER:
> - /* LPI's not implemented */
> + if ( gic_lpi_supported() )
> + {
> + if ( dabt.size != DABT_DOUBLE_WORD ) goto bad_width;
> + /* Remove shareability attribute we don't want dom to flush */
This code doesn't appear to match the code, nothing is removing an
attribute here. Perhaps it belongs next to the place which initialises,
or handles writes to, v->domain->arch.vits->propbase?
> @@ -203,7 +231,18 @@ static int __vgic_v3_rdistr_rd_mmio_write(struct vcpu
> *v, mmio_info_t *info,
> switch ( gicr_reg )
> {
> case GICR_CTLR:
> - /* LPI's not implemented */
> + if ( gic_lpi_supported() )
> + {
> + /*
> + * Enable LPI's for ITS. Direct injection of LPI
> + * by writing to GICR_{SET,CLR}LPIR are not supported
"is not supported"
> + */
> + if ( dabt.size != DABT_WORD ) goto bad_width;
> + vgic_lock(v);
> + v->domain->arch.vgic.gicr_ctlr = (*r) & GICR_CTLR_ENABLE_LPIS;
Extra space after the &.
> @@ -694,6 +755,14 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v,
> mmio_info_t *info)
> *r = ((ncpus - 1) << GICD_TYPE_CPUS_SHIFT |
> DIV_ROUND_UP(v->domain->arch.vgic.nr_spis, 32));
>
> + if ( gic_lpi_supported() )
> + {
> + irq_bits = gic_nr_id_bits();
> + *r |= GICD_TYPE_LPIS;
> + }
> + else
> + irq_bits = get_count_order(vgic_num_irqs(v->domain));
I think gic_nr_id_bits should return the correct thing whether or not
LPIs are supported, i.e.
if ( gic_lpi_supported() )
*r |= GICD_TYPE_LPIS;
irq_bits = gic_nr_id_bits();
should be sufficient.
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 67e4695..49db7f0 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -102,6 +102,7 @@ struct arch_domain
> paddr_t dbase; /* Distributor base address */
> paddr_t cbase; /* CPU base address */
> #ifdef CONFIG_ARM_64
> + int gicr_ctlr;
Wrong indentation
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |