On 04.08.2010, at 18:36, 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. Frankly, I partially agreed to your point when we were talking about 300ms vs. 2 seconds. Now that we're talking 8 seconds that whole point is moot. We chose the wrong interface to transfer kernel+initrd data into the guest. Now the question is how to fix that. I would veto against anything normally guest-OS-visible. By occupying the floppy, you lose a floppy drive in the guest. By occupying a disk, you see an unwanted disk in the guest. By taking virtio-serial you see an unwanted virtio-serial line in the guest. fw_cfg is great because it's a private interface nobody else accesses. I see two alternatives out of this mess: 1) Speed up string PIO so we're actually fast again. 2) Using a different interface (that could also be DMA fw_cfg - remember, we're on a private interface anyways) Admittedly 1 would also help in more cases than just booting with -kernel and -initrd, but if that won't get us to acceptable levels (and yes, 8 seconds for 100MB is unacceptable) I don't see any way around 2. Alex -- 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
