Re: HW Virtualization Abstraction Layer Work Underway

[Arun Sharma <arun.sharma@intel.com>]

[-- Attachment #1: Type: text/plain, Size: 2400 bytes --]

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 
hwassist.

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.

	-Arun

[-- Attachment #2: vmx.png --]
[-- Type: image/png, Size: 11288 bytes --]

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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