On Tuesday 08 July 2014 23:53:21, Mark Kettenis wrote: > Are these paravirtualization APIs stable? Are they (properly) > documented somewhere?
Mostly. So far, I am using three things: 1) the paravirtualized EOI. Documented in Documentation/virtual/kvm/msr.txt in linux source. 2) the MSR to write to the lapic ICR register. This is a Hyper-V interface that is also implemented by KVM. It's documented in the Microsoft Hyper-V docs (don't have a pointer right now). 3) the fact that doing IPIs does not require waiting for the BUSY bit to clear in ICR. This is really an implementation detail in KVM. Unless there is some way to detect this, it's not something that one can depend on by default but it could be enabled by some UKC flag with default off. A different approach would be to add support for x2apic mode, which would take care of 2)+3). But this cannot be mixed with normal accesses to the memory mapped apic registers (xapic mode) and would therefore be a lot more intrusive to implement. > If we're serious about supporting OpenBSD on (KVM) hypervisors, > something like this makes sense. We tend to try and have a single > kernel that runs on the widest range of hardware that is possible. > For example the OpenBSD/sparc64 kernel runs on both sun4u and sun4v > hardware, and the sun4v platforms has written paravirtualization all > over it. There I successfully made use of code patching > techniques. That might help on x86 as well. Yes, code patching may be useful. I haven't noticed it used in openbsd before, but I will take a look at sparc64. > Can't say I'm happy with making the interrupt handling code even > more complicated though... Do you think that putting all lapic operations as function into a apic_ops struct would be preferable? This would make the code much easier to read/maintain at the cost of some indirection and a few function calls in interrupt paths.
