From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47311) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDcD9-0000ND-OF for qemu-devel@nongnu.org; Tue, 11 Oct 2011 09:17:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RDcD7-0004Q8-RA for qemu-devel@nongnu.org; Tue, 11 Oct 2011 09:17:35 -0400 Received: from mail-iy0-f173.google.com ([209.85.210.173]:37488) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDcD7-0004Pz-Mm for qemu-devel@nongnu.org; Tue, 11 Oct 2011 09:17:33 -0400 Received: by iakl21 with SMTP id l21so7066024iak.4 for ; Tue, 11 Oct 2011 06:17:32 -0700 (PDT) Message-ID: <4E9441E8.5050301@codemonkey.ws> Date: Tue, 11 Oct 2011 08:17:28 -0500 From: Anthony Liguori 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> <4E94129A.1080803@redhat.com> In-Reply-To: <4E94129A.1080803@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: Avi Kivity Cc: qemu-devel , "Richard W.M. Jones" , Gleb Natapov , Alexander Graf On 10/11/2011 04:55 AM, Avi Kivity wrote: > 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. Doing kernel loading through fw_cfg has always been a bit ugly. A better approach would be to implement a PCI device with a ROM bar that contained an option ROM that read additional bars from the device to get at the kernel and initrd. That also enables some potentially interesting models like having the additional bars be optionally persisted letting a user have direct control over which kernel/initrds were loaded. It's essentially a PCI device with a flash chip on it that contains a kernel/initrd. Regards, Anthony Liguori >