Re: [Qemu-devel] Slow kernel/initrd loading via fw_cfg; Was Re: Hack integrating SeaBios / LinuxBoot option rom with QEMU trace backends

[Daniel P. Berrange]

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, so mgmt apps don't have to worry
about PCI addressing wrt guest ABI.


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 :|