On Tue, Mar 14, 2017 at 08:55:09AM +0000, Marc Zyngier wrote:
> On Tue, Mar 14 2017 at 8:26:01 am GMT, Christoffer Dall <cdall@xxxxxxxxxx> wrote:
> > On ARM, I think the main benefits of implementing something like
> > handle_external_intr would come from two things: (1) You'd avoid the
> > context synchronization and associated cost of taking an exception on
> > the CPU, and (2) you'd also (potentially) avoid the additional
> > save/restore of all the GP regiters from the kernel exception entry path
> > to create a usable gp_regs.
> >
> > I have to look more careful at whether or not (2) is possible, because
> > it would mean we'd have to store the guest register state on a pt_regs
> > structure in the first place and pass that directly to
> > arch_handle_irq.
>
> For that to be useful on pre-VHE HW and avoid the extra exception
> handling, we'd also have to perform that arch_handle_irq call as part of
> the exception return to EL1. That's not going to be very pretty, as we
> need to build two return contexts (EL2->EL1 IRQ on the host, followed by
> EL1->EL1).
Why do we need something like that?
Why can't we simply call arch_handle_irq from kvm_arch_vcpu_ioctl_run
being in either EL1 or EL2, depending if we have VHE, respectively,
assuming we have a pt_regs struct we can use with the expected semantics
for arch_handle_irq ?
In the first case, we would have completed the EL2->EL1 transition
before attempting to handle IRQs and in the second case we would always
be in EL2, but we would logically be in the same place in the overall
execution flow.
Note, that I'm assuming that you don't need to be directly calling
arch_handle_irq as a result of a minimal set of assembly code directly
following the exception vector, but that arch_handle_irq can be called
as a function from a later time with interrupts disabled as long as the
pt_regs reasonably express the state of the CPU at the time the
exception occurred, which in this case would (most likely) be the
guest's state.
>
> This is all perfectly doable, but as always, we need numbers.
Agreed.
>
> I had similar stuff for VHE a long while ago (back when I wrote WSINC),
> but faking the pt_regs was absolutely horrible. But maybe it is time to
> exhume this again...
>
Correct me if I'm wrong, but I think you're referring to the work where
you used the host's exception vectors, not calling arch_handle_irq from
the run loop, or did I misunderstand?
> > Additionally, if we had something like handle_external_intr, the
> > guest_exit thing would be kinda moot, since we'd do our ticks like
> > x86...
>
> Indeed. Which brings the obvious question: are we the only ones not
> taking the interrupt early?
>
Hmm, I tried taking a look, but my mips/powerpc/s390 fail me slightly.
However, from what I can gather, s390 enables interrupts after returning
from the guest, then disables them again and calls guest_exit_irqoff, so
kinda what we're doing from a performance perspective, only different.
I'm lost in all the versions of the powerpc code that calls
guest_exit{_irqoff}, and it looks to me like mips handles physical
interrupts from the exit path before reaching the guest_exit_irqoff
point.
But I could be completely wrong :-/
Thanks,
-Christoffer
