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
vmx.png
Description: PNG image
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home
