Keir Fraser wrote:
> 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.
I agree. Today the hooks (e.g. when creating, terminating, or switching
domains) are required to do different things for full virtualization
(rather than para-virutalization), and should be exposed as clean
well-defined interface.
>
> 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.
That's right. One thing we should do is to have a common I/O VMEXIT and
MMIO handler. The first-level trap handlers (like vmx_asm_vmexit_handler
or vmx_vmexit_handler) are very specific to each H/W assist
architecture, but we should be able to define common handlers for these
(by slightly modifying the VMX 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
I don't like the name HVAL, either, because of the same reason. What we
are doing is to have _additional_ or dedicated interfaces exposed in Xen
to provide full virtualization in support of H/W assist virtualization.
BTW, I don't think the following is the right abstaraction because the
original arch_vmx_struct was intended to maintain the architectural
state, and it can be different on other H/W assist virtualization. In
fact, we need to add more things to support 64-bit guests. The struct
virtual_platform_def (and flags) should moved out of the architectual
state, and probably arch_svm_struct needs to defined sperately.
struct arch_hval_struct {
union {
struct vmcs_struct *vmcs; //vmx
struct vmcb_struct *vmcb; //svm
}
unsigned long flags; /* VMCS/VMCB flags */
unsigned long cpu_cr2;
unsigned long cpu_cr3;
unsigned long cpu_state;
struct virtual_platform_def hval_platform;
}
Jun
---
Intel Open Source Technology Center
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home