RE: [Xen-devel] HW Virtualization Abstraction Layer Work Underway

["Wahlig, Elsie" <elsie.wahlig@xxxxxxx>]

Nakajima, Jun wrote: 
> 
> That's right. One thing we should do is to have a common I/O 
> VMEXIT and MMIO handler. The first-level trap handlers (like 
> vmx_asm_vmexit_handler or vmx_vmexit_handler) are very 
> specific to each H/W assist architecture, but we should be 
> able to define common handlers for these (by slightly 
> modifying the VMX code). 

The MMIO handler code (handle_mmio entry point in vmx_platform.c) has
been refactored as generic (now hval_platform.c).  The I/O VMEXIT code
handler in vmx_io.c has also been refactored and is now hval_io.c (new
hval_io_assist/hval_intr_assist/hval_do_resume entry points).  The
current vmx exit handler can't be made more generic for SVM.   This will
be in the patch that is coming.  

> 
> > 
> > I dislike the name HVAL though -- it's not very 
> informative. Something 
> > like hwassist, vmassist, hw_vm, or many others would all be 
> preferable 
> > imo.
> > 
> >   -- Keir
> 
> I don't like the name HVAL, either, because of the same 
> reason. What we are doing is to have _additional_ or 
> dedicated interfaces exposed in Xen to provide full 
> virtualization in support of H/W assist virtualization. 
> 

HWASSIST was our original name for it, but was deemed to be too long.  
The names with the vm letters hit many false positives when grepping
code, 
so we avoided all names with 'vm'.   Since this was defining an
interface, 
HVAL was one we went with.  Now if the name matters, we can make it
HWASSIST.  

> BTW, I don't think the following is the right abstaraction 
> because the original arch_vmx_struct was intended to maintain 
> the architectural state, and it can be different on other H/W 
> assist virtualization. In fact, we need to add more things to 
> support 64-bit guests. The struct virtual_platform_def (and 
> flags) should moved out of the architectual state, and 
> probably arch_svm_struct needs to defined sperately.  
> 
> struct arch_hval_struct {
>         union {
>             struct vmcs_struct *vmcs; //vmx
>             struct vmcb_struct *vmcb; //svm
>         }
>         unsigned long  flags;  /* VMCS/VMCB flags */
>         unsigned long  cpu_cr2;
>         unsigned long  cpu_cr3;
>         unsigned long  cpu_state;
>         struct virtual_platform_def hval_platform;
> }        

I don't see why we would need both a arch_vmx_struct and an
arch_svm_struct at one time. 
That physical platform wont ever be built.  The goal is to abstract out
the hardware 
and need only maintain one of the control blocks during it's runtime.
Does your arch
Need a different vmcs for 64-bits?  

Elsie Wahlig


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel