> It would be nice to at least see the patches. :) > > I think a lightweight q35 platform that can run the usual firmware could > be acceptable in QEMU.
OK, I will send out v2. > > >> 2) this: > >> > >>> - it loads guest kernel directly, no BIOS, no bootloader, no realmode > >>> code; > >> > >> ... which is related to Linux-only support. How much does this gain > >> over a minimal firmware (either SeaBIOS with the fw_cfg DMA interface, > >> or qboot with cbfs in parallel flash)? > > > > We have tried Q35 version (as described above) with both SeaBIOS and qboot. > > The 'perfect' time with optimized BIOS we have seen is ~15ms, with the > > additional time in kernel real mode code, the total time overhead comparing > > to current Linux-aware implementation is more than 40ms. This sounds still > > a little too much for us. > > I guess it is related to real mode decompression code? Yes, that's the major part. > > My main issue is that there are other things that the firmware does. > Not all of them are necessary (e.g. SMRAM is not needed, most PCI > devices need not be initialized), but in general we don't like putting > code in QEMU that modifies the guest state. For example another Intel > person is adding code to SeaBIOS that initializes the feature control MSR. > > I wonder if Linux could run as a multiboot-compliant ELF file, and what > the performance would be... Multiboot omits the real mode stub. > I can look into this. Thanks. Chao
