From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37398) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ze3A1-0003w6-TK for qemu-devel@nongnu.org; Mon, 21 Sep 2015 11:37:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ze39x-00051X-6N for qemu-devel@nongnu.org; Mon, 21 Sep 2015 11:37:45 -0400 Received: from mail-vk0-f44.google.com ([209.85.213.44]:32805) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ze39x-000518-3I for qemu-devel@nongnu.org; Mon, 21 Sep 2015 11:37:41 -0400 Received: by vkgd64 with SMTP id d64so67359808vkg.0 for ; Mon, 21 Sep 2015 08:37:40 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <56001E68.10909@redhat.com> References: <20111121171820.16487.92704.malonedeb@chaenomeles.canonical.com> <20150919105456.3836.86017.malone@wampee.canonical.com> <56001E68.10909@redhat.com> From: Peter Maydell Date: Mon, 21 Sep 2015 08:37:21 -0700 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [Bug 893208] Re: qemu on ARM hosts can't boot i386 image List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: Bug 893208 <893208@bugs.launchpad.net>, QEMU Developers , "Dr. David Alan Gilbert (git)" On 21 September 2015 at 08:12, Laszlo Ersek wrote: > Where does the division by zero come from then? Well grub fetches and > stashes the TSC, then programs the PIT to sleep for some time, then > re-fetches the TSC, and uses the TSC difference as denominator when > calculating the "TSC rate". (It has a solid idea of the real time > passed, due to the PIT frequency being a given.) I was wondering rereading the bug report whether this was down to our lousy RDTSC implementation...thanks for digging in and confirming what's going on. > Now, the cpu_get_real_ticks() implementation is *host* specific. You can > find it implemented for a bunch of host architectures in > "include/qemu/timer.h". > I applied the following extremely sophisticated patch (with the motto > "it cannot get more wronger"): > >> diff --git a/include/qemu/timer.h b/include/qemu/timer.h >> index 9939246..def22de 100644 >> --- a/include/qemu/timer.h >> +++ b/include/qemu/timer.h >> @@ -1003,8 +1003,7 @@ static inline int64_t cpu_get_real_ticks(void) >> totally wrong, but hopefully better than nothing. */ >> static inline int64_t cpu_get_real_ticks (void) >> { >> - static int64_t ticks = 0; >> - return ticks++; >> + return get_clock(); >> } >> #endif >> > > get_clock() is CLOCK_MONOTONIC based, has (theoretical) nanosecond > resolution, and a nice flat int64_t encoding that should suffice for > approx. 329 years. This should provide grub with a larger denominator. > > This "fix" allowed me to boot the i386 Debian image on the AARCH64 host. > > For a real fix... I think on AARCH64 hosts at least, a "real" cycle > counter should be available, and someone who knows AARCH64 could write a > function that fetches it. > > For 32-bit ARM, I presume the Raspberry Pi 2 and the Odroid C1 are > advanced enough for a similar cycle counter reading function. There isn't a user-space readable cycle counter on ARM. (There is a counter which might be accessible to userspace depending on kernel config, but the kernel doesn't guarantee its availability as an ABI thing.) Probably we should figure out a sane way to emulate guest cycle counters that isn't dependent on the host CPU architecture. I think having QEMU's behaviour as seen by the guest vary like this is a recipe for confusion. thanks -- PMM