Message ID | 20230928094404.20802-1-michal.orzel@amd.com |
---|---|
State | New |
Headers | show |
Series | [v2] target/arm: Fix CNTPCT_EL0 trapping from EL0 when HCR_EL2.E2H is 0 | expand |
On 28.09.23 12:44, Michal Orzel wrote: Hello Michal > On an attempt to access CNTPCT_EL0 from EL0 using a guest running on top > of Xen, a trap from EL2 was observed which is something not reproducible > on HW (also, Xen does not trap accesses to physical counter). > > This is because gt_counter_access() checks for an incorrect bit (1 > instead of 0) of CNTHCTL_EL2 if HCR_EL2.E2H is 0 and access is made to > physical counter. Refer ARM ARM DDI 0487J.a, D19.12.2: > When HCR_EL2.E2H is 0: > - EL1PCTEN, bit [0]: refers to physical counter > - EL1PCEN, bit [1]: refers to physical timer registers > > Drop entire block "if (hcr & HCR_E2H) {...} else {...}" from EL0 case > and fall through to EL1 case, given that after fixing checking for the > correct bit, the handling is the same. > > Fixes: 5bc8437136fb ("target/arm: Update timer access for VHE") > Signed-off-by: Michal Orzel <michal.orzel@amd.com> > --- > This is now in conformance to ARM ARM CNTPCT_EL0 pseudocode: > if PSTATE.EL == EL0 then > ... > elif EL2Enabled() && HCR_EL2.E2H == '0' && CNTHCTL_EL2.EL1PCTEN == '0' then > AArch64.SystemAccessTrap(EL2, 0x18); > > Changes in v2: > - drop block and fall through to avoid duplication The V2 also works, so my tag is still valid: [with Zephyr running as Xen guest and accessing CNTPCT_EL0 from EL0] Tested-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> > --- > target/arm/helper.c | 17 +---------------- > 1 file changed, 1 insertion(+), 16 deletions(-) > > diff --git a/target/arm/helper.c b/target/arm/helper.c > index 83620787b453..59576aa1575a 100644 > --- a/target/arm/helper.c > +++ b/target/arm/helper.c > @@ -2475,22 +2475,7 @@ static CPAccessResult gt_counter_access(CPUARMState *env, int timeridx, > if (!extract32(env->cp15.c14_cntkctl, timeridx, 1)) { > return CP_ACCESS_TRAP; > } > - > - /* If HCR_EL2.<E2H,TGE> == '10': check CNTHCTL_EL2.EL1PCTEN. */ > - if (hcr & HCR_E2H) { > - if (timeridx == GTIMER_PHYS && > - !extract32(env->cp15.cnthctl_el2, 10, 1)) { > - return CP_ACCESS_TRAP_EL2; > - } > - } else { > - /* If HCR_EL2.<E2H> == 0: check CNTHCTL_EL2.EL1PCEN. */ > - if (has_el2 && timeridx == GTIMER_PHYS && > - !extract32(env->cp15.cnthctl_el2, 1, 1)) { > - return CP_ACCESS_TRAP_EL2; > - } > - } > - break; > - > + /* fall through */ > case 1: > /* Check CNTHCTL_EL2.EL1PCTEN, which changes location based on E2H. */ > if (has_el2 && timeridx == GTIMER_PHYS &&
On Thu, 28 Sept 2023 at 10:44, Michal Orzel <michal.orzel@amd.com> wrote: > > On an attempt to access CNTPCT_EL0 from EL0 using a guest running on top > of Xen, a trap from EL2 was observed which is something not reproducible > on HW (also, Xen does not trap accesses to physical counter). > > This is because gt_counter_access() checks for an incorrect bit (1 > instead of 0) of CNTHCTL_EL2 if HCR_EL2.E2H is 0 and access is made to > physical counter. Refer ARM ARM DDI 0487J.a, D19.12.2: > When HCR_EL2.E2H is 0: > - EL1PCTEN, bit [0]: refers to physical counter > - EL1PCEN, bit [1]: refers to physical timer registers > > Drop entire block "if (hcr & HCR_E2H) {...} else {...}" from EL0 case > and fall through to EL1 case, given that after fixing checking for the > correct bit, the handling is the same. > > Fixes: 5bc8437136fb ("target/arm: Update timer access for VHE") > Signed-off-by: Michal Orzel <michal.orzel@amd.com> Applied to target-arm.next, thanks (sorry for the delay; I've been on holiday ;-)). -- PMM
diff --git a/target/arm/helper.c b/target/arm/helper.c index 83620787b453..59576aa1575a 100644 --- a/target/arm/helper.c +++ b/target/arm/helper.c @@ -2475,22 +2475,7 @@ static CPAccessResult gt_counter_access(CPUARMState *env, int timeridx, if (!extract32(env->cp15.c14_cntkctl, timeridx, 1)) { return CP_ACCESS_TRAP; } - - /* If HCR_EL2.<E2H,TGE> == '10': check CNTHCTL_EL2.EL1PCTEN. */ - if (hcr & HCR_E2H) { - if (timeridx == GTIMER_PHYS && - !extract32(env->cp15.cnthctl_el2, 10, 1)) { - return CP_ACCESS_TRAP_EL2; - } - } else { - /* If HCR_EL2.<E2H> == 0: check CNTHCTL_EL2.EL1PCEN. */ - if (has_el2 && timeridx == GTIMER_PHYS && - !extract32(env->cp15.cnthctl_el2, 1, 1)) { - return CP_ACCESS_TRAP_EL2; - } - } - break; - + /* fall through */ case 1: /* Check CNTHCTL_EL2.EL1PCTEN, which changes location based on E2H. */ if (has_el2 && timeridx == GTIMER_PHYS &&
On an attempt to access CNTPCT_EL0 from EL0 using a guest running on top of Xen, a trap from EL2 was observed which is something not reproducible on HW (also, Xen does not trap accesses to physical counter). This is because gt_counter_access() checks for an incorrect bit (1 instead of 0) of CNTHCTL_EL2 if HCR_EL2.E2H is 0 and access is made to physical counter. Refer ARM ARM DDI 0487J.a, D19.12.2: When HCR_EL2.E2H is 0: - EL1PCTEN, bit [0]: refers to physical counter - EL1PCEN, bit [1]: refers to physical timer registers Drop entire block "if (hcr & HCR_E2H) {...} else {...}" from EL0 case and fall through to EL1 case, given that after fixing checking for the correct bit, the handling is the same. Fixes: 5bc8437136fb ("target/arm: Update timer access for VHE") Signed-off-by: Michal Orzel <michal.orzel@amd.com> --- This is now in conformance to ARM ARM CNTPCT_EL0 pseudocode: if PSTATE.EL == EL0 then ... elif EL2Enabled() && HCR_EL2.E2H == '0' && CNTHCTL_EL2.EL1PCTEN == '0' then AArch64.SystemAccessTrap(EL2, 0x18); Changes in v2: - drop block and fall through to avoid duplication --- target/arm/helper.c | 17 +---------------- 1 file changed, 1 insertion(+), 16 deletions(-)