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 1/24] i386 Vmi documentation

To: Chris Wright <chrisw@xxxxxxxxxxxx>
Subject: [Xen-devel] Re: [RFC, PATCH 1/24] i386 Vmi documentation
From: Daniel Arai <arai@xxxxxxxxxx>
Date: Wed, 15 Mar 2006 14:56:23 -0800
Cc: Zachary Amsden <zach@xxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Pratap Subrahmanyam <pratap@xxxxxxxxxx>, Wim Coekaerts <wim.coekaerts@xxxxxxxxxx>, Joshua LeVasseur <jtl@xxxxxxxxxx>, Dan Hecht <dhecht@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Jack Lo <jlo@xxxxxxxxxx>, Christopher Li <chrisl@xxxxxxxxxx>, Virtualization Mailing List <virtualization@xxxxxxxxxxxxxx>, Linus Torvalds <torvalds@xxxxxxxx>, Anne Holler <anne@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxxxx>, Jyothy Reddy <jreddy@xxxxxxxxxx>, Kip Macy <kmacy@xxxxxxxxxxx>, Ky Srinivasan <ksrinivasan@xxxxxxxxxx>, Leendert van Doorn <leendert@xxxxxxxxxxxxxx>
Delivery-date: Fri, 17 Mar 2006 10:39:34 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20060315025720.GN12807@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: <200603131759.k2DHxeep005627@xxxxxxxxxxxxxxxxxxx> <20060313224902.GD12807@xxxxxxxxxxxxxxxxxx> <4416078C.4030705@xxxxxxxxxx> <20060314212742.GL12807@xxxxxxxxxxxxxxxxxx> <441743BD.1070108@xxxxxxxxxx> <20060315025720.GN12807@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913
Chris Wright wrote:
* Zachary Amsden (zach@xxxxxxxxxx) wrote:

1) can't use stack based args, so have to allocate each data structure,
which could conceivably fail unless it's some fixed buffer.

We use a fixed buffer that is private to our VMI layer. It's a per-cpu packing struct for hypercalls. Dynamically allocating from the kernel inside the interface layer is a really great way to get into a whole lot of trouble.


Heh, indeed that's why I asked.  per-cpu buffer means ROM state knows
which vcpu is current.  How is this done in OS agnostic method w/out
trapping to hypervisor?  Some shared data that ROM and VMM know about,
and VMM updates as it schedules each vcpu?

Each VCPU gets a private data area at the same linear address. The VMM constructs private page table shadows for each VCPU, and the shadows magically contain the right mappings for that VCPU's private data area.

Other hypervisor implementations (especially those that don't make use of shadow page tables) would have to come up with something along the lines that you're suggesting.

Dan.

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