On Sat, 2015-07-11 at 20:25 +0200, Julien Grall wrote:
> Hi,
>
> On 10/07/2015 17:10, Ian Campbell wrote:
> > 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.
>
> Well no. The field GICD_TYPER.IDbits represents the number of bits
> supported for the interrupt identifier.
>
> The guest may have a different number of IDbits than the hardware which
> could be higher (for instance a guest where emulated SPI is supported).
Yes, I really meant vgic_nr_id_bits(), which might for the dom0 case end
up returning something related to the h/w value from the appropriate
vgic hw cfg struct.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
