Re: [Xen-devel] [PATCH 4/9] xen: arm: turn vtimer traps for cp32/64 and sysreg into #undef

[Julien Grall <julien.grall@xxxxxxxxxx>]

Hi Ian,

On 09/09/14 09:23, Ian Campbell wrote:
> We have allowed EL1 to access these registers directly for some time
> (at least since 4.3.0). They were only ever trapped to support very
> early models which had a buggy hypervisor timer, requiring us to use
> the phys timer for Xen itself.
> In the interests of minimising the patch for the security update just
> remove the call to vtimer_emulate and inject an #undef exception. In
> practice we will never see any of these traps.
I disagree with the commit message, a guest may use the physical timer 
rather than the virtual timer. It's the case when a guest doesn't have 
the necessary code to use the virtual timer.
Hence, the guest could decide to let the userspace access to CNTPCT_EL0 
(see CNTKCTL.PL0CTEN). In a such case, the application will be broken on 
Xen guest.
> Handle CNTPCT_EL0 explicitly for consistency with CNTPCT on 32-bit.
>
> Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> ---
>   xen/arch/arm/traps.c |   37 ++++++++++++-------------------------
>   1 file changed, 12 insertions(+), 25 deletions(-)
>
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 353e38e..46ed21d 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -1478,13 +1478,8 @@ static void do_cp15_32(struct cpu_user_regs *regs,
>           break;
>       case HSR_CPREG32(CNTP_CTL):
>       case HSR_CPREG32(CNTP_TVAL):
> -        if ( !vtimer_emulate(regs, hsr) )
You dropped every call to vtimer_emulate. It may be interesting to 
remove the related code in vtimer.c
Regards,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel