On Tue, Dec 30, 2014 at 11:19 AM, Anup Patel <anup@xxxxxxxxxxxxxx> wrote: > (dropping previous conversation for easy reading) > > Hi Marc/Christoffer, > > I tried implementing PMU context-switch via C code > in EL1 mode and in atomic context with irqs disabled. > The context switch itself works perfectly fine but > irq forwarding is not clean for PMU irq. > > I found another issue that is GIC only samples irq > lines if they are enabled. This means for using > irq forwarding we will need to ensure that host PMU > irq is enabled. The arch_timer code does this by > doing request_irq() for host virtual timer interrupt. > For PMU, we can either enable/disable host PMU > irq in context switch or we need to do have shared > irq handler between kvm pmu and host kernel pmu. > > I have rethinked about our discussion so far. I > understand that we need KVM PMU virtualization > to meet following criteria: > 1. No modification in host PMU driver > 2. No modification in guest PMU driver > 3. No mask/unmask dance for sharing host PMU irq > 4. Clean way to avoid infinite VM exits due to > PMU interrupt > > I have discovered new approach which is as follows: > 1. Context switch PMU in atomic context (i.e. local_irq_disable()) > 2. Ensure that host PMU irq is disabled when entering guest > mode and re-enable host PMU irq when exiting guest mode if > it was enabled previously. This is to avoid infinite VM exits > due to PMU interrupt because as-per new approach we > don't mask the PMU irq via PMINTENSET_EL1 register. > 3. Inject virtual PMU irq at time of entering guest mode if PMU > overflow register is non-zero (i.e. PMOVSSET_EL0) in atomic > context (i.e. local_irq_disable()). > > The only limitation of this new approach is that virtual PMU irq > is injected at time of entering guest mode. This means guest > will receive virtual PMU interrupt with little delay after actual > interrupt occurred. The PMU interrupts are only overflow events > and generally not used in any timing critical applications. If we > can live with this limitation then this can be a good approach > for KVM PMU virtualization. > > Regards, > Anup Hi Marc/Christoffer, Ping?? Regards, Anup -- 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
