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