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).
Furthermore, I'm against in principle to call directly GIC function in the vGIC. We spent time to introduced various vGIC structure per domain which stores the specific information for the emulated GIC (such as the number of SPIs). It's not time to break it, even though we'd like to see the ITS code in Xen 4.6.
I don't think it's too hard to do and will avoid to forget it when guest support will be added...
Regards, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
