This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel] HW Virtualization Abstraction Layer Work Underway
From: "Wahlig, Elsie" <elsie.wahlig@xxxxxxx>
Date: Mon, 6 Jun 2005 22:48:41 -0500
Delivery-date: Tue, 07 Jun 2005 03:48:08 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcVqdebRDR1EnNEjQwOdqhQrQvmT7QANUv8wAAycwZA=
Thread-topic: [Xen-devel] HW Virtualization Abstraction Layer Work Underway

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
so we avoided all names with 'vm'.   Since this was defining an
HVAL was one we went with.  Now if the name matters, we can make it

> 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