[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.