Re: [Qemu-devel] [PATCH v4 4/5] acpi: arm: add fw_cfg device node to dsdt

From: Laszlo Ersek <lersek@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Andrew Jones" <drjones@redhat.com>,
	"Matt Fleming" <matt.fleming@intel.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Gabriel L. Somlo" <somlo@cmu.edu>,
	"Ard Biesheuvel" <ard.biesheuvel@linaro.org>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"Leif Lindholm" <leif.lindholm@linaro.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Shannon Zhao" <zhaoshenglong@huawei.com>,
	"Igor Mammedov" <imammedo@redhat.com>,
	"Marc Marí" <markmb@redhat.com>,
	"Kevin OConnor" <kevin@koconnor.net>,
	"Richard Henderson" <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH v4 4/5] acpi: arm: add fw_cfg device node to dsdt
Date: Wed, 30 Sep 2015 14:22:26 +0200	[thread overview]
Message-ID: <560BD402.4020003@redhat.com> (raw)
In-Reply-To: <CAFEAcA9ZkRMCZqXUfOmia=GdL6yrto_aaMPUsEWJB7v9GtSKFA@mail.gmail.com>

On 09/30/15 13:13, Peter Maydell wrote:
> On 30 September 2015 at 11:21, Laszlo Ersek <lersek@redhat.com> wrote:
>> However: if Gabriel has no access to actual aarch64 hardware (ie. cannot
>> run KVM guests), then I don't think he should bother. Booting just the
>> UEFI firmware on qemu-system-aarch64 with TCG acceleration is fine, but
>> for checking "/proc/iomem", he'd really need to boot into guest Linux,
>> and *that* takes absolutely forever with TCG.
> 
> If it actually takes forever that's a bug of some sort I think.
> TCG isn't all that snappy but it shouldn't take more than a few
> minutes to boot and it should be at least usably responsive on
> the command line once you get there. (Best not to try to boot
> into a GUI, though.)

Yes, TCG is fast, relative to the feat it pulls off, but in absolute
terms, even those minutes to boot are annoying when you repeatedly test
something in the guest.

Here's a timing from my new company laptop (Thinkpad W541, i7-4810MQ CPU
@ 2.80GHz, running docked); QEMU built with --enable-debug:

(1) From starting the guest until the EFI stub of the kernel launches:
omitted (we're not timing the firmware, as it is not universally
necessary for testing)

(2) From launching the EFI stub until the login prompt appears on the
serial console: 3 minutes 46 seconds

(3) After logging in super fast, the time it takes to get a shell
prompt: 50 seconds

(4) The time it takes for background services to quiesce (= for QEMU to
stop spinning) while waiting idly at the shell prompt (because it makes
no sense to issue commands earlier): 1 minute 19 seconds

(5) Once the guest quiesces, shutting it down with "poweroff": 1 minute
36 seconds.

In total, 7 minutes 31 seconds for a test cycle (not counting the
firmware), without running any actual commands in the guest.

Again, it depends on the services that are enabled in systemd, but you
usually want to test with a guest OS that users normally run.

(I realize step (5) can be avoided if you have a qcow2 snapshot -- just
kill the guest when you're done, and revert the image to the snapshot
before next boot; hopefully new guest files are not important. I also
agree the first investment in a TCG guest should be heavily trimming its
services.)

So -- there's no bug, but TCG does not appear very suitable for testing
in guest userspace *now*.

... This is not to diminish TCG's general brilliance, and usefulness in
certain situations. I haven't forgotten that aarch64 emulation in TCG
was a long awaited godsend after the Foundation Model!

Still: Gabriel, how do you feel about buying a 96Boards EE (when it
becomes available)? :)

https://www.96boards.org/products/ee/
http://community.arm.com/people/jeffunderhill/status/9831
https://community.amd.com/community/amd-business/blog/2015/06/23/extending-arm-s-ecosystem-for-server-developers

Thanks
Laszlo