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 Thanks Laszlo
