Re: [Xen-devel] vgic initialization with maximum number of interrupt lines fails

[Lukas Jünger <lukas.juenger@xxxxxxxxxxxxxxxxxx>]

Hi,

On 3/22/19 5:12 PM, Julien Grall wrote:
> Hi,
>
> On 22/03/2019 15:39, Lukas Jünger wrote:
> > On 3/22/19 4:20 PM, Julien Grall wrote:
> > > On 22/03/2019 13:30, Lukas Jünger wrote:
> > > > I use Xen in an ARMv8 simulator for research purposes.
> > > > I ran into the following problem during dom0 creation in vgic 
> > > > initialization.
> > > > Bringup fails because -EINVAL is returned by the code below.
> > > >
> > > > xen/arch/arm/vgic.c in domain_vgic_init():
> > > > 132     nr_spis = ROUNDUP(nr_spis, 32);
> > > > 133
> > > > 134     /* Limit the number of virtual SPIs supported to (1020 - 32) 
> > > > = 988  */
> > > > 135     if ( nr_spis > (1020 - NR_LOCAL_IRQS) )
> > > > 136         return -EINVAL;
> > > >
> > > > nr_spis comes from config->arch.nr_spis in xen/arch/arm/domain.c in 
> > > > arch_domain_create():
> > > > 702     if ( (rc = domain_vgic_init(d, config->arch.nr_spis)) != 0 )
> > > > 703         goto fail;
> > > >
> > > > arch.nr_spis comes from xen/arch/arm/setup.c in start_xen():
> > > > 891     dom0_cfg.arch.nr_spis = gic_number_lines() - 32;
> > > >
> > > > gic_number_lines() in xen/arch/arm/gic.c:
> > > > 62 unsigned int gic_number_lines(void)
> > > > 63 {
> > > > 64     return gic_hw_ops->info->nr_lines;
> > > > 65 }
> > > >
> > > > populated in xen/arch/arm/gic-v2.c in gicv2_dist_init:
> > > > 354     type = readl_gicd(GICD_TYPER);
> > > > 355     nr_lines = 32 * ((type & GICD_TYPE_LINES) + 1);
> > > > 356     /* Only 1020 interrupts are supported */
> > > > 357     nr_lines = min(1020U, nr_lines);
> > > > 358     gicv2_info.nr_lines = nr_lines;
> > > >
> > > > GICv2 supports up to 1020 interrupts.
> > > > In this case type will be (type & GICD_TYPE_LINES) will be 31, as 
> > > > the bits [4:0] of GICD_TYPER will be 1.
> > > > nr_lines will be 1024 and finally reduced to 1020, because of 
> > > > special purpose interrupts.
> > > > Later it will be rounded up to 1024 again and then the check will fail.
> > > > Is this expected behavior and if yes, why?
> > > This is a known issues I haven't had time to properly fix yet. The 
> > > GIC requires a multiple of 32 interrupts. In addition, the 2 vGIC 
> > > implementation rely that all "existing" interrupts are fully 
> > > implemented.
> > > Some of the last lot of 32 interrupts (IRQ 992 - IRQ 1023) contains 
> > > special purpose interrupts. The special purpose interrupts are not 
> > > fully implemented. So it would expose a potential vulnerability issue 
> > > if we were supporting up to 1020
> > > interrupts.
> > I was not aware that there were special interrupts starting from IRQ 
> > 992. The GICv2 architecture spec mentions only IRQ1020-1023 to be 
> > special (Section 3.2.5).
> Sorry, I wasn't clear enough. You are right, Only interrupts 1020-1023 
> are special, the interrupts 992-1019 are still valid. However, because 
> of the design of the vGIC, we require all interrupts in a range of 32 
> interrupts to be valid. That's why we limit to 992 interrupts.
Ah, I see. Thanks for the input.

> > > This is why we limit to 992 interrupts. As Dom0 exposes the same 
> > > number of interrupts as the host, this is an issue on platform where 
> > > the GIC report 1024 interrupts. AFAIK, those platforms are only 
> > > virtual, so my idea was to limit the number interrupts exposed to 
> > > Dom0. Something like:
> > > dom0_cfg.arch.nr_spis = min(gic_number_lines(), 992) - 32;
> > >
> > > Does you platform have interrupts wired above 992?
> > In my simulator I just reduced the number of interrupts reported to be 
> > available by the GICv2 model. This solves the issue for my use case.
> Thank you for the confirmation. So a patch like above in Xen should work 
> for us.
Should I submit a patch, or do you just patch this yourself? Do you want 
to limit to 992 or 980 like the original code does?
> OOI, which simulator are you using?
It's something based on QEMU, but the GICv2 model is from VCML 
(https://github.com/janweinstock/vcml).

> Cheers,
Thanks,
Lukas

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel