On Thu, Feb 22, 2018 at 10:02:48AM +0100, Christoffer Dall wrote:
> On Wed, Feb 21, 2018 at 11:34:07AM +0000, Marc Zyngier wrote:
> > On Thu, 15 Feb 2018 21:02:55 +0000,
> > Christoffer Dall wrote:
> > > @@ -138,13 +138,15 @@ alternative_else_nop_endif
> > >
> > > el1_irq:
> > > stp x0, x1, [sp, #-16]!
> > > - ldr x1, [sp, #16 + 8]
> > > + get_host_ctxt x0, x1
> > > + get_vcpu x1, x0
> > > mov x0, #ARM_EXCEPTION_IRQ
> > > b __guest_exit
> > >
> > > el1_error:
> > > stp x0, x1, [sp, #-16]!
> > > - ldr x1, [sp, #16 + 8]
> > > + get_host_ctxt x0, x1
> > > + get_vcpu x1, x0
> >
> > Given how frequent this construct is, would there be a benefit in
> > having something like "get_vcpu_ptr" that conflates the two macros? We
> > don't seem to have a single case of using get_vcpu on its own.
> >
>
> I think my intention was to make it obvious how we get to the vcpu
> pointer, but looking at it now I don't think this adds anything, so I'm
> happy to adjust. How about adding a get_vcpu_ptr macro which calls the
> other two macros?
>
Do we really need three macros, if get_vcpu is never used independently?
In the first round of reviews I suggested redefining get_vcpu like this
"""
.macro get_vcpu vcpu, tmp
get_host_ctxt \tmp, \vcpu
ldr \vcpu, [\tmp, #HOST_CONTEXT_VCPU]
kern_hyp_va \vcpu
.endm
which also has the side-effect of tmp being ctxt after the call.
"""
Thanks,
drew
