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

[Chao Peng]

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 doesn't support PCIe hotplug though, I think? (Because it doesn't
> support PCI bridges and PCIe hotplug doesn't work for root complex
> devices).  So is it ACPI-based hotplug?

Yes, this is ACPI-based.

> 
> 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?

> 
> Anyway, I guess all the items above are acceptable.
> 
> The ones that I think are "less acceptable" are just two. :)
> 
> 1) I am a bit worried about introducing a custom northbridge and PM
> device.  In principle you could remove most ISA devices (especially
> those that take long to initialize) and the 8259 while keeping Q35 and
> ICH9.  This would make it easier to choose between having a firmware and
> direct guest kernel load.
> 
> In general I'd model the lightweight devices around Q35 and ICH9, not
> PIIX.  ICH9 in particular is good because it integrates the PM device
> and it has an ISA bridge for the RTC and perhaps an optional 8250.  But
> it would be even better to use Q35 and ICH9, not model around them. :)

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.

One example: we saw smram/pam in Q35 causes guest boot time decrease so
we want to strip them off, we change Q35 for our case (ifdef or
whatever) but this changes the way guest sees it and also may not be in
accord with Q35 spec.

I'm not strongly insist on this. Also reuse Q35 in QEMU can make code in
other place (like BIOS) be reused as well (if not cause problem).

> 
> 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.

One solution is to support both direct Linux booting and BIOS booting with a
little overhead (but with more flexibility).

> 
> 
> > - it supports KVM-host only at present;
> 
> Do you know why?

Just because we have never tested that on other hypervisors (like Xen).

Thanks for comments and suggestions.

Chao