WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [RFC, PATCH 5/24] i386 Vmi code patching

To: Chris Wright <chrisw@xxxxxxxxxxxx>
Subject: [Xen-devel] Re: [RFC, PATCH 5/24] i386 Vmi code patching
From: Joshua LeVasseur <jtl@xxxxxxxxxx>
Date: Sat, 18 Mar 2006 01:49:03 +0100
Cc: Zachary Amsden <zach@xxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Pratap Subrahmanyam <pratap@xxxxxxxxxx>, Jyothy Reddy <jreddy@xxxxxxxxxx>, Wim Coekaerts <wim.coekaerts@xxxxxxxxxx>, Chris Wright <chrisw@xxxxxxxx>, Jack Lo <jlo@xxxxxxxxxx>, Dan Hecht <dhecht@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxxxx>, Christopher Li <chrisl@xxxxxxxxxx>, Virtualization Mailing List <virtualization@xxxxxxxxxxxxxx>, Linus Torvalds <torvalds@xxxxxxxx>, Anne Holler <anne@xxxxxxxxxx>, Pavel Machek <pavel@xxxxxx>, Kip Macy <kmacy@xxxxxxxxxxx>, Ky Srinivasan <ksrinivasan@xxxxxxxxxx>, Leendert van Doorn <leendert@xxxxxxxxxxxxxx>, Dan Arai <arai@xxxxxxxxxx>
Delivery-date: Mon, 20 Mar 2006 10:42:01 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20060317211146.GP15997@xxxxxxxxxxxxxxxxxx>
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>
References: <200603131802.k2DI2nv8005665@xxxxxxxxxxxxxxxxxxx> <20060315230012.GA1919@xxxxxxxxxx> <869E58AF-339F-4660-8458-36F58A5E35EF@xxxxxxxxxx> <20060317211146.GP15997@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

On Mar 17, 2006, at 22:11 , Chris Wright wrote:

* Joshua LeVasseur (jtl@xxxxxxxxxx) wrote:
extern "C" void
afterburn_cpu_write_gdt32_ext( burn_clobbers_frame_t *frame )
{
    get_cpu()->gdtr =  *(dtr_t *)frame->eax;
}

What is this get_cpu()?  Accessing data structure that's avail. in ROM
and shared with hypervisor...could you elaborate a bit here?

thanks,
-chris


VMI is a very versatile interface due to the ROM; within the ROM you can translate the instruction set architecture and device register activity (as represented by the VMI interface) to a variety of hypervisor interfaces. I use a virtual CPU to help perform the translation. The performance of virtualization depends on the extent to which you can minimize interaction with the hypervisor via hypercalls. Many of the operations needn't be exposed to the hypervisor, and only operate on the virtual CPU, and thus remain completely within the ROM. The goal is to minimize interaction with the hypervisor.

I don't share the virtual CPU with the hypervisor. There probably are performance benefits for codesign between the hypervisor and ROM, but I haven't had that luxury; I take the hypervisors as given and none of them are fundamentally designed to use a ROM. On the other hand, it makes sense to concentrate virtualization within the ROM, rather than the hypervisor, for the same arguments you can make for implementing functionality in an application rather than the kernel.

I've implemented ROMs for two (open source) hypervisors so far, and try to share as much code between them as possible. The get_cpu() is an abstraction to help hide the hypervisor specifics for locating the virtual CPU (and it handles multiprocessor issues).

To help illustrate the role of the ROM, consider using Linux as a hypervisor, i.e., Linux-on-Linux but with the guest kernel using the VMI interface [1]. The ROM would translate the low-level operations of the guest kernel into the system calls of the host Linux, and it would be important to minimize the amount of interaction with the host Linux. Consider interrupt delivery, which would probably be mapped to POSIX signals. VMI offers VMI_EnableInterrupts(), VMI_DisableInterrupts(), VMI_GetInterruptMask(), and VMI_SetInterruptMask(). All of these operations are executed frequently by Linux, and it would be critical to limit their side effects to within the ROM; for performance reasons, they mustn't map to POSIX signal mask/unmask operations. The solution is to update only the EFLAGS in the virtual CPU when the guest kernel invokes VMI_EnableInterrupts, DisableInterrupts, etc.. Then the ROM must always accept asynchronous POSIX signal delivery, and must only forward asynchronous events to the guest kernel if interrupts are enabled in the virtual CPU. If the virtual CPU's interrupts are disabled, then the event is only recorded in the virtual PIC, and delivered at the next VMI_EnableInterrupts() or VMI_SetInterruptMask().

[1] Linux-on-Linux would probably limp with the current VMI. A couple changes would be necessary, such as permitting the Linux kernel to run at ring 3, and offering put_user() and get_user() hooks, since the guest applications and guest kernel must use different host address spaces. Unfortunately, put_user() and get_user () hooks are higher-level interfaces that don't fit well within VMI. For other CPU architectures with only two privilege levels, put_user () and get_user() hooks may be necessary too.


Joshua



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel