On 14/03/17 11:12, Christoffer Dall wrote:
> 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 ?
Ah, that's where you want to perform the call. I was thinking of doing
it a bit earlier and save another few instructions by performing the
eret directly into the interrupt handler. I'm probably trying to
optimizing too early, as usual!
>
> 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?
Yes, that's what I had in mind, but you're obviously thinking of
performing the call differently, so please ignore me until I come to my
senses...
>>> 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 :-/
Well, it at least shows that there is a variety of ways to handle
interrupts on exit, and that the patch you quoted earlier in the thread
may have affected more than just ARM.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
