From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54247) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDcee-0006NU-Oc for qemu-devel@nongnu.org; Tue, 11 Oct 2011 09:46:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RDceZ-0003xC-4i for qemu-devel@nongnu.org; Tue, 11 Oct 2011 09:46:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63678) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDceY-0003x0-P4 for qemu-devel@nongnu.org; Tue, 11 Oct 2011 09:45:55 -0400 Message-ID: <4E94488C.30405@redhat.com> Date: Tue, 11 Oct 2011 15:45:48 +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> <050FFBD4-BF45-4425-865B-24E7C228B592@suse.de> <4E9440B6.3060201@codemonkey.ws> <2DB3FD25-4BF7-4F82-9A62-49A6891316B3@suse.de> <4E944252.7020508@codemonkey.ws> <4E944358.6030304@redhat.com> <4E9444A9.9050507@codemonkey.ws> In-Reply-To: <4E9444A9.9050507@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 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: Anthony Liguori Cc: "Richard W.M. Jones" , qemu-devel , Gleb Natapov , Alexander Graf On 10/11/2011 03:29 PM, Anthony Liguori wrote: > On 10/11/2011 08:23 AM, Avi Kivity wrote: >> On 10/11/2011 03:19 PM, Anthony Liguori wrote: >>>> No, DMA has a lot bigger granularities in kvm/user interaction. We >>>> can easily DMA a 50MB region with a single kvm/user exit. For PIO we >>>> can at most do page granularity. >>> >>> >>> So make a proper PCI device for kernel loading. It's a much more >>> natural approach and let's use alias -kernel/-initrd/-append to >>> -device kernel-pci,kernel=PATH,initrd=PATH >> >> This is overkill. First let's optimize rep/movs before introducing any >> more interfaces. If that doesn't work, then we can have a dma interface >> for fwcfg. But a new pci device? > > This is how it would work on bare metal. Why is a PCI device overkill > compared to a dma interface for fwcfg? > Because it's a limited use case, despite all the talk around it. > If we're adding dma to fwcfg, then fwcfg has become far too complex > for it's intended purpose. > I have to agree to that. btw, -net nic,model=virtio -net user is an internal DMA interface we already have. We can boot from it. Why not use it? -- error compiling committee.c: too many arguments to function