From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:58244) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDdP7-00065h-T6 for qemu-devel@nongnu.org; Tue, 11 Oct 2011 10:34:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RDdP2-00084K-95 for qemu-devel@nongnu.org; Tue, 11 Oct 2011 10:34:01 -0400 Received: from mail-iy0-f173.google.com ([209.85.210.173]:45777) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDdP2-00084E-0o for qemu-devel@nongnu.org; Tue, 11 Oct 2011 10:33:56 -0400 Received: by iakl21 with SMTP id l21so7165247iak.4 for ; Tue, 11 Oct 2011 07:33:55 -0700 (PDT) Message-ID: <4E9453CD.50608@codemonkey.ws> Date: Tue, 11 Oct 2011 09:33:49 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <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> <20111011140150.GD4485@redhat.com> In-Reply-To: <20111011140150.GD4485@redhat.com> Content-Type: text/plain; charset=UTF-8; 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: "Daniel P. Berrange" Cc: qemu-devel , Alexander Graf , Avi Kivity , Gleb Natapov , "Richard W.M. Jones" On 10/11/2011 09:01 AM, Daniel P. Berrange wrote: > On Tue, Oct 11, 2011 at 08:19:14AM -0500, Anthony Liguori wrote: >> On 10/11/2011 08:14 AM, Alexander Graf wrote: >>>>>>> And I don't see the point why we would have to shoot yet another hole into the guest just because we're too unwilling to make an interface that's perfectly valid horribly slow. >>>>>> >>>>>> 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. >>>>> >>>>> Whatever we do, the interface will never be as fast as DMA. We will always have to do sanity / permission checks for every IO operation, can batch up only so many IO requests and in QEMU again have to call our callbacks in a loop. >>>> >>>> rep/ins is effectively equivalent to DMA except in how it's handled within QEMU. >>> >>> 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 > > Adding a PCI device doesn't sound very appealing, unless you > can guarentee it is never visible to the guest once LinuxBoot > has finished its dirty work, It'll definitely be guest visible just like fwcfg is guest visible. Regards, Anthony Liguori so mgmt apps don't have to worry > about PCI addressing wrt guest ABI. > > > Daniel