On 12/14/2010 06:04 PM, Anthony Liguori wrote:
On 12/14/2010 09:38 AM, Avi Kivity wrote:
Fortunately, we have a very good bytecode interpreter that's
accelerated in the kernel called KVM ;-)
We have exactly the same bytecode interpreter under a different name,
it's called userspace.
If you can afford to make the transition back to the guest for
emulation, you might as well transition to userspace.
If you re-entered the guest and setup a stack that had the RIP of the
source of the exit, then there's no additional need to exit the
guest. The handler can just do an iret. Or am I missing something?
I didn't even consider an iret-to-guest, to be honest. Let's consider
the options:
- iret-to-guest (a la tpr patching) - need to have an executable page
in the guest virtual address space and some stack space (on 64-bit, can
rely on iretq switching the stack). That is probably impossible to do
in a generic way without guest cooperation. If we rely on guest
cooperation, we might as well have the guest patch the IN instruction
itself (no exits at all).
- architectural SMM - no need to find a virtual mapping, or even a
physical page, since we're in our own physical address space. However,
the RSM instruction will trap, and on Intel, at least the first few
instructions need to be emulated since SMM starts in big real mode.
Also needs a tlb flush.
- kvm-specific SMM (probably what you referred to as "paravirt SMM", but
if the guest OS is not involved, it's not really paravirt) - can switch
to our own cr3 so no problem with finding a virtual mapping; however
still needs a tlb flush, and on pre-NPT/EPT machines, switching cr3 back
will involve an exit.
We already have a virtual address space that works for most guests
thanks to the TPR optimization.
It only works for Windows XP and Windows XP with the /3GB extension.
Is this a fundamental limitation or just a statement of today's
heuristics? Does any guest not keep the BIOS in virtual memory in a
static location?
If you're looking for a fundamental limitation, then yes, a guest need
not map the BIOS at all. Practically, I believe all common guest do map
the BIOS, but IIRC modern guests use non-executable mappings.
--
error compiling committee.c: too many arguments to function
--
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
