Re: [RFC PATCH 0/6] ARM64: KVM: PMU infrastructure support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



(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
--
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



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux