[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen master] xen/arm: vtimer: Don't read/use the secure physical timer interrupt for ACPI
commit 6432228fb5808150d3c5c14affb3d46af81b3878 Author: Julien Grall <jgrall@xxxxxxxxxx> AuthorDate: Thu Oct 5 17:52:41 2023 +0100 Commit: Julien Grall <jgrall@xxxxxxxxxx> CommitDate: Mon Oct 16 10:36:16 2023 +0100 xen/arm: vtimer: Don't read/use the secure physical timer interrupt for ACPI Per ACPI 6.5 section 5.2.25 ("Generic Timer Description Table (GTDT)"), the fields "Secure EL1 Timer GSIV/Flags" are optional and an OS running in non-secure world is meant to ignore the values. However, Xen is trying to reserve the value. The ACPI tables for Graviton 2 metal instances will provide the value 0 which is not a correct PPI (PPIs start at 16) and would have in fact been already reserved by Xen as this is an SGI. Xen will hit the BUG() and panic(). For the Device-Tree case, I couldn't find a statement suggesting that the secure physical timer interrupt is ignored. In fact, I have found some code in Linux using it as a fallback. That said, it should never be used. As I am not aware of any issue when booting using Device-Tree, the physical timer interrupt is only ignored for ACPI. Signed-off-by: Julien Grall <jgrall@xxxxxxxxxx> Reviewed-by: Michal Orzel <michal.orzel@xxxxxxx> Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx> Release-acked-by: Henry Wang <Henry.Wang@xxxxxxx> --- xen/arch/arm/time.c | 4 ---- xen/arch/arm/vtimer.c | 17 +++++++++++++++-- 2 files changed, 15 insertions(+), 6 deletions(-) diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c index 04b07096b1..09cae8138e 100644 --- a/xen/arch/arm/time.c +++ b/xen/arch/arm/time.c @@ -78,10 +78,6 @@ static int __init arch_timer_acpi_init(struct acpi_table_header *header) irq_set_type(gtdt->non_secure_el1_interrupt, irq_type); timer_irq[TIMER_PHYS_NONSECURE_PPI] = gtdt->non_secure_el1_interrupt; - irq_type = acpi_get_timer_irq_type(gtdt->secure_el1_flags); - irq_set_type(gtdt->secure_el1_interrupt, irq_type); - timer_irq[TIMER_PHYS_SECURE_PPI] = gtdt->secure_el1_interrupt; - irq_type = acpi_get_timer_irq_type(gtdt->virtual_timer_flags); irq_set_type(gtdt->virtual_timer_interrupt, irq_type); timer_irq[TIMER_VIRT_PPI] = gtdt->virtual_timer_interrupt; diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c index c54360e202..d2124b1755 100644 --- a/xen/arch/arm/vtimer.c +++ b/xen/arch/arm/vtimer.c @@ -8,6 +8,7 @@ * Copyright (c) 2011 Citrix Systems. */ +#include <xen/acpi.h> #include <xen/lib.h> #include <xen/perfc.h> #include <xen/sched.h> @@ -61,10 +62,22 @@ int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig *config) config->clock_frequency = timer_dt_clock_frequency; - /* At this stage vgic_reserve_virq can't fail */ + /* + * Per the ACPI specification, providing a secure EL1 timer + * interrupt is optional and will be ignored by non-secure OS. + * Therefore don't reserve the interrupt number for the HW domain + * and ACPI. + * + * Note that we should still reserve it when using the Device-Tree + * because the interrupt is not optional. That said, we are not + * expecting any OS to use it when running on top of Xen. + * + * At this stage vgic_reserve_virq() is not meant to fail. + */ if ( is_hardware_domain(d) ) { - if ( !vgic_reserve_virq(d, timer_get_irq(TIMER_PHYS_SECURE_PPI)) ) + if ( acpi_disabled && + !vgic_reserve_virq(d, timer_get_irq(TIMER_PHYS_SECURE_PPI)) ) BUG(); if ( !vgic_reserve_virq(d, timer_get_irq(TIMER_PHYS_NONSECURE_PPI)) ) -- generated by git-patchbot for /home/xen/git/xen.git#master
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |