From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50708) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDcHn-0004zc-6R for qemu-devel@nongnu.org; Tue, 11 Oct 2011 09:22:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RDcHi-0005kT-0O for qemu-devel@nongnu.org; Tue, 11 Oct 2011 09:22:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:27213) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDcHh-0005kL-Of for qemu-devel@nongnu.org; Tue, 11 Oct 2011 09:22:17 -0400 Date: Tue, 11 Oct 2011 15:22:11 +0200 From: Gleb Natapov Message-ID: <20111011132211.GZ30105@redhat.com> 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> <4E9441E8.5050301@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E9441E8.5050301@codemonkey.ws> 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: Anthony Liguori Cc: qemu-devel , Alexander Graf , Avi Kivity , "Richard W.M. Jones" On Tue, Oct 11, 2011 at 08:17:28AM -0500, Anthony Liguori wrote: > 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. I thought about this too. But sizes of initrd people mentioning here a crazy. We can run out of pci space very quickly. We can implement one of the BARs as sliding window into initrd though. > > 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. > -- Gleb.