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

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] HW Virtualization Abstraction Layer Work Underway
From: "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Date: Mon, 6 Jun 2005 11:06:35 -0700
Cc: Xen-devel@xxxxxxxxxxxxxxxxxxx, "Wahlig, Elsie" <elsie.wahlig@xxxxxxx>
Delivery-date: Mon, 06 Jun 2005 18:06:00 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcVqdebRDR1EnNEjQwOdqhQrQvmT7QANUv8w
Thread-topic: [Xen-devel] HW Virtualization Abstraction Layer Work Underway
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;

Intel Open Source Technology Center

Xen-devel mailing list