On Mon, Jun 20, 2016 at 08:54:10AM +0200, Paolo Bonzini wrote: > > > On 20/06/2016 08:01, Chao Peng wrote: > > On Fri, Jun 17, 2016 at 03:24:59PM +0200, Paolo Bonzini wrote: > >> > >> > >> On 17/06/2016 10:14, Chao Peng wrote: > >>> Basically: > >>> - it removes old ISA devices and support only PCI devices; > >> > >> I think you need to keep at least the RTC, otherwise where does Linux > >> get the time of day from? > > > > PV clock will provide that. > > It's KVM only, though. Sometimes TCG is useful for debugging. > > >> Lack of 8250/16550 means lack of earlyprintk. I know the driver is slow > >> though, so I understand that. > > > > Understand, it might be a little bit hard for debugging, one solution > > would be adding 8250/16550 in debug build? > > The serial port is optional anyway, it's not there unless you specify > "-serial stdio" or similar. > > > We actually have patches for Q35 + ICH9 and it does exactly the same > > thing you described here. Adding a new one is just: > > 1). to keep both Q35 and 'lite' code clean, and > > 2). don't expose two different Q35 implementations to guest. > > 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.
I agree. > >> 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? > > 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), BTW there's a CMOS flag that says guest is PNP and so only boot devices need to be initialized. seabios could use it and skip non bootable PCI devices. > 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. > > Paolo
