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). This is all perfectly doable, but as always, we need numbers. 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... > 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? Thanks, M. -- Jazz is not dead, it just smell funny.
