On Wed, Aug 04, 2010 at 11:44:33AM -0500, Anthony Liguori wrote: > On 08/04/2010 11:36 AM, Avi Kivity wrote: > > On 08/04/2010 07:30 PM, Avi Kivity wrote: > >> On 08/04/2010 04:52 PM, Anthony Liguori wrote: > >>>>> > >>>>This is not like DMA event if done in chunks and chunks can be pretty > >>>>big. The code that dials with copying may temporary unmap some pci > >>>>devices to have more space there. > >>> > >>> > >>>That's a bit complicated because SeaBIOS is managing the PCI > >>>devices whereas the kernel code is running as an option rom. > >>>I don't know the BIOS PCI interfaces well so I don't know how > >>>doable this is. > >>> > >>>Maybe we're just being too fancy here. > >>> > >>>We could rewrite -kernel/-append/-initrd to just generate a > >>>floppy image in RAM, and just boot from floppy. > >> > >>How could this work? the RAM belongs to SeaBIOS immediately > >>after reset, it would just scribble over it. Or worse, not > >>scribble on it until some date in the future. > >> > >>-kernel data has to find its way to memory after the bios gives > >>control to some optionrom. An alternative would be to embed > >>knowledge of -kernel in seabios, but I don't think it's a good > >>one. > >> > > > >Oh, you meant host RAM, not guest RAM. Disregard. > > > >This is basically my suggestion to libguestfs: instead of > >generating an initrd, generate a bootable cdrom, and boot from > >that. The result is faster and has a smaller memory footprint. > >Everyone wins. > > Yeah, but we could also do that entirely in QEMU. If that's what we > suggest doing, there's no reason not to do it instead of the option > rom trickery that we do today. > > The option rom stuff has a number of short comings. Because we > hijack int19, extboot doesn't get to run. That means that if you > use -kernel to load a grub (the Ubuntu guys for their own absurd > reasons) then grub does not see extboot backed disks. The solution > for them is the same, generate a proper disk and boot from that > disk. > Extboot is not so relevant any more. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
