From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57983) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDaVB-0003Qa-RU for qemu-devel@nongnu.org; Tue, 11 Oct 2011 07:28:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RDaV7-0003io-MW for qemu-devel@nongnu.org; Tue, 11 Oct 2011 07:28:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:14398) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDaV7-0003ic-Bn for qemu-devel@nongnu.org; Tue, 11 Oct 2011 07:28:01 -0400 Message-ID: <4E94284C.2000005@redhat.com> Date: Tue, 11 Oct 2011 13:28:12 +0200 From: Gerd Hoffmann MIME-Version: 1.0 References: <20111002132436.GD11521@bow.tlv.redhat.com> In-Reply-To: <20111002132436.GD11521@bow.tlv.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Spice-devel] viewing continuous guest virtual memory as continuous in qemu List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, spice-devel@freedesktop.org, Dave Airlie Hi, > AFAIU this works only when the guest allocates a continuous range of > physical pages. This is a large requirement from the guest, which I'd > like to drop. Is it? The world is moving to huge pages, with all the stuff needed for it like moving around userspace pages to compact memory and make huge page allocation easier. I think these days it is alot easier to allocate 2M of continuous physical memory than it used to be a few years ago. At least on linux, dunno about windows. When allocating stuff at boot time (say qxl kms driver) allocating even larger chunks shouldn't be a big issue. And having a single big guest memory chunk, then register that as qxl memory slot is what works best with the existing interfaces I guess. Another option we can think about is a 64bit PCI bar for the surfaces which can be moved out of the low 4G. > So I would like to have the guest use a regular > allocator, generating for instance two sequential pages in virtual > memory that are scattered in physical memory. Those two physical > guest page addresses (gp1 and gp2) correspond to two host virtual > memory addresses (hv1, hv2). I would now like to provide to > spice-server a single virtual address p that maps to those two pages > in sequence. Playing mapping tricks like this doesn't come for free. When doing it this way we probaby still want to register a big chunk of memory as qxl memory slot so we have the mapping cost only once, not for each and every surface we create and destroy. cheers, Gerd