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: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] HW Virtualization Abstraction Layer Work Underway
From: Arun Sharma <arun.sharma@xxxxxxxxx>
Date: Mon, 6 Jun 2005 16:41:17 -0700
Cc: Xen-devel@xxxxxxxxxxxxxxxxxxx, "Wahlig, Elsie" <elsie.wahlig@xxxxxxx>, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Delivery-date: Mon, 06 Jun 2005 23:40:07 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <34097cacc44f4157a38dfb790528c506@xxxxxxxxxxxx>
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>
References: <7F740D512C7C1046AB53446D37200173042AE781@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <34097cacc44f4157a38dfb790528c506@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
On Mon, Jun 06, 2005 at 10:02:10AM +0100, Keir Fraser wrote:
> We need to consider the low-level interfaces too, because we do not 
> want a separate set of hooks into the generic Xen code for each 
> different vendor mechanism. We will of course want to adapt this layer 
> to ensure it doesn't hide any value-add extensions, but the principle 
> of hiding as much non-generic detail as possible behind a common 
> interface still remains.
> Also, many opportunities for special hw assistance occur early during 
> trap into Xen (e.g., why did we trap out of the guest context?). 
> Regardless of any common interface, the vendor-specific hwassist code 
> has full control at that point, and can decide what it handles itself 
> and how it interacts with common Xen code.
> 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.

Since vmassist is used by other Xen code, we should probably go with 

In the attached diagram, I've attempted to draw a picture of where we
are today (no eggs or rotten tomatoes please - I don't draw boxes often :)

I think the following points are clear to me:

- The interface between xen/x86 and the box labelled "VMX infrastructure"
  needs to be generic (let's call the interface hwassist and the box
  hwassist infrastructure). This interface already seems to be well defined
  and it might just be a renaming that's required.

- The interface between the cpu and the low level code is going to be
  vendor specific (the box labelled vmexit/vmresume)

- The box labelled "vmx platform" represents the PC platform being emulated
  (partly in xen, rest in ioemu). This is abstracted already by:

  struct virtual_platform_def in vmx_platform.h

  I think it makes sense to share this code.

- We need to define an interface between the vmexit box and the virtual 
  platform box. This interface should not be very low level (something like 
  __vmread(regX) sounds too low level to me). store_cpu_user_regs(), 
  check_guest_faults(), inject_exception() etc sound like a better abstraction.

- There may be more sharing opportunities which are not too disruptive
  elsewhere, but until we have a second implementation, we may not know 
  what they are. So we'd like to defer any interface changes until we have 
  a second implementation.


Attachment: vmx.png
Description: PNG image

Xen-devel mailing list