From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43288 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oao1B-0003EO-V8 for qemu-devel@nongnu.org; Mon, 19 Jul 2010 06:56:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oao1A-0002l6-Tf for qemu-devel@nongnu.org; Mon, 19 Jul 2010 06:56:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:29609) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oao1A-0002kv-Lv for qemu-devel@nongnu.org; Mon, 19 Jul 2010 06:56:16 -0400 Date: Mon, 19 Jul 2010 13:56:14 +0300 From: Gleb Natapov Message-ID: <20100719105614.GT4689@redhat.com> References: <20100717133930.GC19767@amd.home.annexia.org> <20100719101504.GA5216@amd.home.annexia.org> <20100719104500.GS4689@redhat.com> <20100719104909.GV13194@amd.home.annexia.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100719104909.GV13194@amd.home.annexia.org> Subject: [Qemu-devel] Re: [PATCH 0/2 version 2] fw_cfg: Implement fast "DMA"-type operation for rapidly copying in kernel, initrd [etc] into the guest List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Richard W.M. Jones" Cc: qemu-devel@nongnu.org, agraf@suse.de On Mon, Jul 19, 2010 at 11:49:09AM +0100, Richard W.M. Jones wrote: > On Mon, Jul 19, 2010 at 01:45:00PM +0300, Gleb Natapov wrote: > > On Mon, Jul 19, 2010 at 11:15:04AM +0100, Richard W.M. Jones wrote: > > > > > > This is the second version of the patch. > > > > > > We don't use the word "blit" any more, instead this is replaced with > > > "DMA", even though it's not quite like a DMA operation on physical > > > hardware. > > > > > You ignored the whole discussion above. Calling things DMA will not make > > them so. You haven't event implemented Alexander's suggestion to poll > > for DMA completion which will at lease make the interface to the guest > > palatable. > > I read everything in the discussion. > > I can add polling however. > If copying (call to cpu_physical_memory_write()) really takes 6 or more seconds we should really make it async from the beginning. (If we are going this way at all. I prefer to use virtio-serial for such complex gust/host communication. fw_cfg was designed to be simple at should stay so. And it is used by other arches too so any extension should be usable there). -- Gleb.