Re: [Xen-devel] hvm trapping mechanism

["Liu, Jinsong" <jinsong.liu@xxxxxxxxx>]

Andrew Cooper wrote:
> On 23/12/2013 21:01, xennn wrote:
>> Hi all,
>> 
>> I would like to ask about hvm xen implementation. As far i
>> understood the trapping-emulating flow is that:
>> 
>> 1. when hvm virtual machine is started vmcs is setup and a vm_exit
>> handler is registered at: 
>> 
>>  __vmwrite(HOST_RIP, (unsigned long)vmx_asm_vmexit_handler);

Right. From os/vmm programmer point of view, vmexit is a h/w process: when 
guest os running at non-root mode and when some condition satisfied (say, 
external interrupt, sensitive instructions excuted) it will drop to root mode 
hypervisor, enter point of which is defined by HOST_RIP of vmcs --> 
vmx_asm_vmexit_handler --> vmx_vmexit_handler.

You can refer Intel SDM 3, chapter 25 for causes of vmexit, and chapter 27 for 
detail process of vmexit.

Thanks,
Jinsong

>> 
>> 2. the hypercall page is defined by hypercall api and that hypercall
>> page contains the vmexit calls. 
>> 3. when guest os issues syscall an hypercall is perfomed by the
>> hypercall page and vmexit operation is peformed
>> 4. the vmx_vmexit_handler(struct cpu_user_regs *regs) (vmx.c) is
>> invoked to emulate the hypercall. 
>> 
>> I would like to ask is this flow is right? Is there
>> somethingimportant missing? I would like to ask how the 
>> vmx_vmexit_handler is invoked - may  be on hardware level or there
>> is some other party at the flow? 
>> 
>> best regerds
> 
> Technically, the hypercall page contains 'vmcall' instructions.  There
> is no such thing as a vmexit instruction.  A vmexit is the action of
> the processor moving from non-root mode into root mode because of an
> action requiring the intervention of the hypervisor.
> 
> vmx_asm_vmexit_handler is the handler for all vmexits, the vast
> majority 
> of which are not from hypercalls.  It includes may other things, such
> as validity checks when the guest writes to control registers, or
> simply 
> that the real processor received an interrupt and that Xen should
> handle it. 
> 
> ~Andrew
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel