From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37303) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QBhzO-0004ek-DW for qemu-devel@nongnu.org; Mon, 18 Apr 2011 02:31:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QBhzN-00044l-K6 for qemu-devel@nongnu.org; Mon, 18 Apr 2011 02:31:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38639) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QBhzN-00044g-9N for qemu-devel@nongnu.org; Mon, 18 Apr 2011 02:31:13 -0400 Message-ID: <4DABDAAB.7060801@redhat.com> Date: Mon, 18 Apr 2011 09:31:07 +0300 From: Avi Kivity MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Para-virtualized ram-based filesystem? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Ritchie, Stuart" Cc: "qemu-devel@nongnu.org" On 04/18/2011 06:28 AM, Ritchie, Stuart wrote: > On 4/17/11 5:43 AM, "Avi Kivity" wrote: > > >On 04/16/2011 02:58 AM, Ritchie, Stuart wrote: > >> > > >> >You can do this with ivshmem today. You give it a path to a shared > >> >memory file, and then there's a path in sysfs that you can mmap() in > >> >userspace in the guest. > >> > >> Please correct me if I am wrong, but with ivshmem you must to manage > >>your > >> world within a single, fixed size region. I appreciate the simplicity > >>of > >> mapping the whole region all in one go, but our requirements are a bit > >> different. Even if you could pass multiple -device ivshmem instances, > >> it's still a fixed environment. Right? > >> > > > >You could place a read-only filesystem (say iso9660) in the region and > >mount it; it will then appear as a complete filesystem. > > We've thought about formatting the region as a ramdisk, but the block > layer shields mmap() from the storage, thus requiring a data copy into the > page-cache. The great thing about ramfs/tmpfs is the data is used > in-place; we'd lose that when going with a ramdisk or other real > filesystem. s390 uses a trick to achieve this (XIP). Look at fs/ext2/xip.c. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.