Re: [Qemu-devel] [RFC 0/9] Introduce light weight PC platform pc-lite

[Michael S. Tsirkin]

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