Re: Nested SVM and migration

[Zachary Amsden <zamsden@redhat.com>]

On 02/21/2010 04:43 AM, Joerg Roedel wrote:
> On Sun, Feb 21, 2010 at 03:40:55PM +0200, Avi Kivity wrote:
>    
>> On 02/21/2010 03:14 PM, Avi Kivity wrote:
>>      
>>> (Either synthetic msrs, or an new state ioctl).  The state would
>>> contain a bit that says whether the guest is in guest or host mode.
>>>
>>> However, since we're breaking the architecture one way or another,
>>> let's just go with the synthetic INTR intercept.
>>>
>>>        
>> On the other hand, there is no equivalent intercept in vmx.  The
>> "external interrupt" exit can be configured to run an INTACK cycle and
>> capture the vector in a vmcs field, and there's no vector we can insert
>> there (Xen for example uses this).
>>      
> Difficult. We could use an instruction intercept which has no side
> effect on guest state (invlpg for example). But thats a lot more
> dangerous than an INTR intercept. What about PENDING_INTERRUPT? Are
> there hypervisors that may get confused getting this intercept without
> asking for it?
>    

Yes, hypervisors which never mean to handle exits will break.  There are 
many possible reasons you might design such a hypervisor; security, 
non-trivial software lock-out of SVM, special hardware concern, research 
project, or perhaps just a shell hypervisor which has one module capable 
of handling exits, and one module which doesn't require it, used for 
high performance but still maintaining binary compatibility with the 
underlying OS.

Perhaps it is just a guest bug, but any design which disallows this is 
visibly and fundamentally architecturally broken.

On the other hand, architectural effects of a new state ioctl or MSR 
update which is properly implemented are completely invisible to the 
guest.  I don't have a strong preference which way that is done, but I 
do have a very strong preference not to break the architecture.

Zach