From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36298) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDdSK-0000Gk-8A for qemu-devel@nongnu.org; Tue, 11 Oct 2011 10:37:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RDdSI-0008VZ-MN for qemu-devel@nongnu.org; Tue, 11 Oct 2011 10:37:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39183) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDdSI-0008VU-FW for qemu-devel@nongnu.org; Tue, 11 Oct 2011 10:37:18 -0400 Date: Tue, 11 Oct 2011 15:36:59 +0100 From: "Daniel P. Berrange" Message-ID: <20111011143659.GE4485@redhat.com> References: <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> <4E9453CD.50608@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4E9453CD.50608@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 Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel , Alexander Graf , Avi Kivity , Gleb Natapov , "Richard W.M. Jones" On Tue, Oct 11, 2011 at 09:33:49AM -0500, Anthony Liguori wrote: > 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. The difference is that fwcfg doesn't provide any real problems to the guest OS. PCI devices will. Also this means that if you have an existing VM booting with -kernel and you update to a newer QEMU binary, the guest ABI changes due to the new PCI device :-( Unless we keep the old code around forever too, which means we'd really want to improve the old code anyway. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|