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

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

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