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

[Daniel P. Berrange]

On Tue, Jun 28, 2016 at 06:10:51PM +0800, Chao Peng wrote:
> On Thu, Jun 23, 2016 at 01:55:06PM +0100, Daniel P. Berrange wrote:
> > On Mon, Jun 20, 2016 at 02:12:17PM +0800, Chao Peng wrote:
> > > On Sun, Jun 19, 2016 at 06:51:04AM +0300, Michael S. Tsirkin wrote:
> > > > On Fri, Jun 17, 2016 at 04:14:08AM -0400, Chao Peng wrote:
> > > > > - it is FAST;
> > > > 
> > > > Any numbers to demonstrate just how fast it is and fast at what?
> > > 
> > > On a 2.30GHz Haswell server, guest kernel booting time is 59.9ms by
> > > following test steps listed at
> > > 
> > > https://github.com/chao-p/qemu-lite-tools
> > > 
> > > Ran the same test with "-machine q35", the guest kernel booting
> > > time is 129.8ms. There is additional 75ms in SeaBIOS for Q35 case.
> > 
> > I think it'd be useful / interesting to understand why we have saved
> > this time vs Q35. I'm not a huge fan of the idea of defining an
> > arbitrarily cut down machine type, because inevitably one applications
> > view of what is the "bare minimum required functionality" will be
> > different from another applications' view.
> > 
> > It seems to me that whether some features emulated by QEMU are slow
> > or not should only matter if the guest OS actually tries to use those
> > features. IOW, could we achieve the same speed up in boot time, by
> > making Linux more configurable at runtime. eg so with a single Linux
> > kernel binary and standard Q35/PIIX machine type, we can disable
> > slow functionality by just giving Linux suitable kernel command
> > line arguments.
> 
> I totally agree with you. And our goal is reducing boot time so I don't
> mind using existing code to achieve this goal.
> 
> When I looked into this. I have thought there might be a minimal
> platform with which I can add other stuff on demand, or a full
> functional platform that allow me to disable unnecessary functionalities.
> 
> But in practice I can't get a system that exactly fit for me, regardless
> there is lots of configuration methods in both QEMU/BIOS/kernel.
> 
> Taking kernel time overhead with Q35 here for example. The most time
> saving comes from PCI initialization. New pc-lite platform supports only
> 1 bus so guest don't need to scan all the possible buses which save ~60ms.
> Another time saving place is new pc-lite platform removed SMBUS/SATA/LPC
> bridges that Q35 creates by default. Initialization for these devices
> costs ~20ms.
> 
> The problem is not all these functionalities can be disabled either in
> kernel or in QEMU, so in the end, turns out to introduce a new one.

I know that can't be disable in *current* kernel / QEMU. What i'm suggesting
is that you enhance the kernel / QEMU to allow more features to be disabled
dynamically. Adding yet another machine type with a static fixed set of
hardware will only ever suit niche use cases which happen to match whatever
you've personally decided is important, while adding long term support
burden on QEMU for yet another machine. IMHO it is a better long term
payout to make existing kernel/qemu more dynamically configurable instead
of adding yet another non-dynamic machine.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|