Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751625AbWCOW4Z (ORCPT ); Wed, 15 Mar 2006 17:56:25 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751818AbWCOW4Z (ORCPT ); Wed, 15 Mar 2006 17:56:25 -0500 Received: from mailout1.vmware.com ([65.113.40.130]:30470 "EHLO mailout1.vmware.com") by vger.kernel.org with ESMTP id S1751625AbWCOW4Y (ORCPT ); Wed, 15 Mar 2006 17:56:24 -0500 Message-ID: <44189B97.2040802@vmware.com> Date: Wed, 15 Mar 2006 14:56:23 -0800 From: Daniel Arai User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Wright Cc: Zachary Amsden , Linus Torvalds , Linux Kernel Mailing List , Virtualization Mailing List , Xen-devel , Andrew Morton , Dan Hecht , Anne Holler , Pratap Subrahmanyam , Christopher Li , Joshua LeVasseur , Rik Van Riel , Jyothy Reddy , Jack Lo , Kip Macy , Jan Beulich , Ky Srinivasan , Wim Coekaerts , Leendert van Doorn Subject: Re: [RFC, PATCH 1/24] i386 Vmi documentation References: <200603131759.k2DHxeep005627@zach-dev.vmware.com> <20060313224902.GD12807@sorel.sous-sol.org> <4416078C.4030705@vmware.com> <20060314212742.GL12807@sorel.sous-sol.org> <441743BD.1070108@vmware.com> <20060315025720.GN12807@sorel.sous-sol.org> In-Reply-To: <20060315025720.GN12807@sorel.sous-sol.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1353 Lines: 31 Chris Wright wrote: > * Zachary Amsden (zach@vmware.com) 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/