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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2015-01-14 at 16:57 +0000, Julien Grall wrote:
> Hi Ian,
> 
> On 14/01/15 16:33, Ian Campbell wrote:
> > On Thu, 2014-09-11 at 09:43 +0100, Ian Campbell wrote:
> >> On Wed, 2014-09-10 at 11:54 -0700, Julien Grall wrote:
> >>> Hi Ian,
> >>>
> >>> On 10/09/14 02:46, Ian Campbell wrote:
> >>>> On Tue, 2014-09-09 at 16:31 -0700, Julien Grall wrote:
> >>>>> 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.
> > 
> > I was just about to dive back into this and was thinking: Is a guest
> > which uses the phys timer something we actually wish to support? We
> > already require the guest to paravirtualise other aspects of its life,
> > and requiring vtimer doesn't seem to step outside that boundary.
> 
> Currently if a developer wants to support his OS on Xen, he only has to
> add PV drivers (assuming DT support is there). It doesn't have to modify
> the core of the OS.
> 
> This will be the case with requiring the vtimer. Futhermore, it can be
> tricky to implement it on some OS. For instance, the OS may decide to
> expose the timer to the user space. Any change would mean recompiler all
> the user space for running on Xen.
> 
> > Supporting the ptimer is going to take some effort as well as the
> > existing code+overhead in Xen.
> 
> We already support the physical timer. May I ask, what kind of effort
> are necessary?

It needs a bunch of refactoring to handle the sysreg vs cp-reg aspects
in order to support 32 bit userspace on top of 64 bit guest kernel,
which is a lot of faff.

But I think the better approach would be to fix the vtimer mask-on-irq
thing (by using GICD I[SC]ACTIVER to context switch the state) and then
apply the same principal to the ptimer and do proper context switching
-- i.e. allow guests to access the physical timers directly.

I'm looking into the vtimer masking and ctxt switching the irq state
now, once I've got that going exposing the ptimer directly to guests
ought to be pretty simple.

> > Do we know of any existing supported OSes which use the phys timer?
> 
> AFAIK no. Even though FreeBSD, while it's not supported, the physical
> timer is used by default.

Sounds to me like the phys timer is a defacto part of our ABI, then,
since something in the real world is using it, which justifies the
effort in supporting it.

Ian.


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