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