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

[Gabriel L. Somlo]

On Wed, Sep 30, 2015 at 02:22:26PM +0200, Laszlo Ersek wrote:
> On 09/30/15 13:13, Peter Maydell wrote:
> > On 30 September 2015 at 11:21, Laszlo Ersek <address@hidden> 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

Hmm, that looks like a sweet piece of hardware, and I can definitely
think of a few excuses I can bring up with my boss to order me one or
two :) Any idea how long until they're for sale ?

Also, Laszlo -- thanks for testing on arm! I'll fire off v5 with all
the feedback I collected soon, hopefully early tomorrow. I've been
trying to squeeze in work on the kernel driver between meetings today,
and on second look, I think I can immitate enough of pvpanic's setup
and tear-down to replace my module_init and module_exit routines, and
make this an acpi-only driver. We'll see how that works out, thanks
again for the pointers !

--Gabriel