Hi Jan,
On Thu, 18 Oct 2012, Jan Kiszka wrote:
There is also the kvmvapic, but kvm does not expose a sane interface
to it and only uses it for Windows XP specific binary patching.
The kvmvapic is not a classic paravirtual interface in that it does not
really require guest OS awareness. But it requires the guest to accept
being patched. That's the case for certain Windows versions. Also, the
option ROMs, including our kvmvapic "ROM", have to be mapped at fixed,
accessible addresses to allow jumping to it from a patched TPR instructions.
Therefore, we limited the patching to known OS versions, avoiding to
mess around with other, untested OSes. However, it may be possible to
accept OpenBSD as well by adjusting the tests in kvmvapic and possibly
adjusting some other details.
The problem I see here is that OpenBSD is, other than Windows XP, still a
moving target and details like the offsets in the cpu info struct may
change in the future. So some interface where the guest OS provides the
necessary details may be nicer.
Another possibility is TPR access via CR8 on AMD, but the missing
cr8_legacy CPUID bit and this discussion [1] make me believe that this
is not supported under kvm, at least in 32bit mode. Could this be
easily fixed? If yes, would it solve the performance problems, i.e.
offer performance comparable to Intel's flexpriority feature?
Everything that unconditionally traps, and so do CR8 accesses, does not
help.
I was hoping that CR8 access would not trap unconditionally. The AMD
Programmer's Manual Vol. 2, section 15.21.2 seems to imply that there is a
mode where this is not the case:
<quote>
SVM provides a virtual TPR register, V_TPR, for use by the guest; its
value is loaded from the VMCB by VMRUN and written back to the VMCB by
#VMEXIT. The APIC's TPR always controls the task priority for physical
interrupts, and the V_TPR always controls virtual interrupts.
While running a guest with V_INTR_MASKING cleared to 0:
* Writes to CR8 affect both the APIC's TPR and the V_TPR register
* Reads from CR8 operate as they would without SVM
While running a guest with V_INTR_MASKING set to 1:
* Writes to CR8 affect only the V_TPR register
* Reads from CR8 return V_TPR.
</quote>
Is V_INTR_MASKING == 1 not used in kvm? Is it not usable at all for some
reason? Or have I misunderstood the description?
It would be more likely that other hypervisors add support for CR8
access than that they add kvmvapic compatibility. Therefore such a
solution would seem preferable, if it is possible.
Cheers,
Stefan
--
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
