Hi Marc, On 06/10/2015 11:03 AM, Marc Zyngier wrote: > Hi Eric, > > On 10/06/15 09:33, Eric Auger wrote: >> Hi Marc, >> On 06/08/2015 07:03 PM, Marc Zyngier wrote: >>> From day 1, our timer code has been using a terrible hack: whenever >>> the guest is scheduled with a timer interrupt pending (i.e. the HW >>> timer has expired), we restore the timer state with the MASK bit set, >>> in order to avoid the physical interrupt to fire again. And again. And >>> again... >>> >>> This is absolutely silly, for at least two reasons: >>> >>> - This relies on the device (the timer) having a mask bit that we can >>> play with. Not all devices are built like this. >>> >>> - This expects some behaviour of the guest that only works because the >>> both the kernel timer code and the KVM counterpart have been written >>> by the same idiot (the idiot being me). >>> >>> The One True Way is to set the GIC active bit when injecting the >>> interrupt, and to context-switch across the world switch. This is what >>> this series implements. >>> >>> We introduce a relatively simple infrastructure enabling the mapping >>> of a virtual interrupt with its physical counterpart: >>> >>> - Whenever an virtual interrupt is injected, we look it up in an >>> rbtree. If we have a match, the interrupt is injected with the HW >>> bit set in the LR, together with the physical interrupt. >>> >>> - Across the world switch, we save/restore the active state for these >>> interrupts using the irqchip_state API. >>> >>> - On guest EOI, the HW interrupt is automagically deactivated by the >>> GIC, allowing the interrupt to be resampled. >> >> I am lost about the status of the irqchip part, allowing EOImode=1 and >> only dropping the prio for physical forwarded IRQs: >> http://lkml.iu.edu/hypermail/linux/kernel/1410.3/00913.html >> Doesn't this series also depend on those patches or did I miss something >> on the ML? > > No, these patches are self-contained. As long as we only deal with > shared devices, we don't need EOImode=1, as as we save/restore the > active state, and the only irqchip change required (the state accessors) > went in with the 4.1 merge window. > > The EOImode=1 stuff is still on the cards, and this series contains the > basic infrastructure for that (the last patch in the series is there > only for that purpose). > > Hope this helps, OK thanks. I am currently rebasing my kvm-vfio series on yours. I will let you know the outcome. Best Regards Eric > > M. > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
