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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 6 Jun 2005, at 09:15, Nakajima, Jun wrote:

> Since the handling of the CPU architectural state (as
> handled by vmx.c and vmx_vmcs.c today, for example) is specific to each
> virtualization technology and can be optimized more if the code is 
> aware
> of the technolgy, for a common interface I think we should focus on the
> virtual platform area (i.e. configration definition & domain builder,
> device models, I/O request notifcation, I/O VMEXIT handler, instruction
> decoder for MMIO, etc.), rather than dealing with broader or vague "HW
> Virtualization."
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.
 -- Keir


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