[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.