Re: [RFC 0/4] KVM in-kernel PM Timer implementation

[Avi Kivity <avi@redhat.com>]

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