From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47021) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDZ3q-0005XQ-8A for qemu-devel@nongnu.org; Tue, 11 Oct 2011 05:55:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RDZ3p-0006mi-10 for qemu-devel@nongnu.org; Tue, 11 Oct 2011 05:55:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:24291) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDZ3o-0006mZ-Mc for qemu-devel@nongnu.org; Tue, 11 Oct 2011 05:55:44 -0400 Message-ID: <4E94129A.1080803@redhat.com> Date: Tue, 11 Oct 2011 11:55:38 +0200 From: Avi Kivity MIME-Version: 1.0 References: <20111010170803.GV9408@redhat.com> <4E933F2D.7090703@codemonkey.ws> <20111011082315.GI14627@redhat.com> <4E940919.7010901@redhat.com> <5C80782F-C30A-4F35-93FD-0397A1040AFF@suse.de> <4E940BB6.2000400@redhat.com> <20111011095048.GU30105@redhat.com> In-Reply-To: <20111011095048.GU30105@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Slow kernel/initrd loading via fw_cfg; Was Re: Hack integrating SeaBios / LinuxBoot option rom with QEMU trace backends List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: "Richard W.M. Jones" , Alexander Graf , qemu-devel On 10/11/2011 11:50 AM, Gleb Natapov wrote: > On Tue, Oct 11, 2011 at 11:26:14AM +0200, Avi Kivity wrote: > > rep/ins is exactly like dma+wait for this use case: provide an > > address, get a memory image in return. There's no need to add > > another interface, we should just optimize the existing one. > > > rep/ins cannot be optimized to be as efficient as dma and remain to > be correct at the same time. There are various corner cases that > simplified "fast" implementation will likely miss. Like DF flag > settings, delaying interrupts for too much, doing ins/outs to/from > iomem (this is may be not a big problem unless userspace finds a way > to trigger it). There are ways that current implementation can be > optimized still though. These can all go through the slow path, except interrupts, which need to be checked after every access. > But loading MBs of data through fw_cfg interface is just abusing it. > You wouldn't use pio on real HW to move megabytes of data and expect > good performance. True, this is a point in favour of a true dma interface. -- error compiling committee.c: too many arguments to function