From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NjbWi-0002Wv-Tl for qemu-devel@nongnu.org; Mon, 22 Feb 2010 11:52:57 -0500 Received: from [199.232.76.173] (port=56753 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NjbWi-0002WQ-7r for qemu-devel@nongnu.org; Mon, 22 Feb 2010 11:52:56 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NjbWd-0003yo-Nr for qemu-devel@nongnu.org; Mon, 22 Feb 2010 11:52:55 -0500 Received: from mail-ww0-f45.google.com ([74.125.82.45]:58020) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NjbWb-0003xb-77 for qemu-devel@nongnu.org; Mon, 22 Feb 2010 11:52:49 -0500 Received: by wwi18 with SMTP id 18so420441wwi.4 for ; Mon, 22 Feb 2010 08:52:47 -0800 (PST) Message-ID: <4B82B655.2000408@codemonkey.ws> Date: Mon, 22 Feb 2010 10:52:37 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Address translation - virt->phys->ram References: <4B828DC2.3000609@collabora.co.uk> <4B829645.5020904@codemonkey.ws> <4B82B4E3.2040805@collabora.co.uk> In-Reply-To: <4B82B4E3.2040805@collabora.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ian Molton Cc: qemu-devel@nongnu.org On 02/22/2010 10:46 AM, Ian Molton wrote: > Anthony Liguori wrote: > > >> cpu_physical_memory_map(). >> >> But this function has some subtle characteristics. It may return a >> bounce buffer if you attempt to map MMIO memory. There is a limited >> pool of bounce buffers available so it may return NULL in the event that >> it cannot allocate a bounce buffer. >> >> It may also return a partial result if you're attempting to map a region >> that straddles multiple memory slots. >> > Thanks. I had found this, but was unsure as to wether it was quite what > I wanted. (also is it possible to tell when it has (eg.) allocated a > bounce buffer?) > > Basically, I need to get buffer(s) from guest userspace into the hosts > address space. The buffers are virtually contiguous but likely > physically discontiguous. They are allocated with malloc() and theres > nothing I can do about that. > > The obvious but slow solution would be to copy all the buffers into nice > virtio-based scatter/gather buffers and feed them to the host that way, > however its not fast enough. > Why is this slow? Regards, Anthony Liguori > Right now I have a little driver I have written that allows a buffer to > be mmap()ed by the guest userspace, and this is pushed to the host via > virtio s/g io when the guest calls fsync(). This buffer contains the > data that must be passed to the host, however this data may often > contain pointers to (that is, userspace virtual addresses of) buffers of > unknown sizes which the host also needs to access. These buffers are > what I need to read from the guests RAM. > > The buffers will likely remain active across multiple different calls to > the host so their pages will need to be available. As the calls always > happen when that specific process is active, I'd guess the worst we need > to do is generate a page fault to unswap the page(s). Can that be caused > by qemu (under kvm)? > > It seems that cpu_physical_memory_map() deals with physically contiguous > areas of guest address space. I need to get a host-side mapping of a > *virtually* contiguous (possibly physically discontiguous) set of guest > pages. If this can be done, it'd mean direct transfer of data from guest > application to host shared library, which would be a major win. > > -Ian >