From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 36851C433FE for ; Wed, 9 Dec 2020 14:39:22 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6F4E220829 for ; Wed, 9 Dec 2020 14:39:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6F4E220829 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:52854 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kn0ci-00053l-9L for qemu-devel@archiver.kernel.org; Wed, 09 Dec 2020 09:39:20 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:42212) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kn0Q3-0005qp-UM for qemu-devel@nongnu.org; Wed, 09 Dec 2020 09:26:15 -0500 Received: from mail-ed1-x532.google.com ([2a00:1450:4864:20::532]:43992) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kn0Q2-0002Zq-3q for qemu-devel@nongnu.org; Wed, 09 Dec 2020 09:26:15 -0500 Received: by mail-ed1-x532.google.com with SMTP id q16so1740847edv.10 for ; Wed, 09 Dec 2020 06:26:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TeonSrKFIrS7BL6SFpjAf7TUwrVOapkDWirTh+WY03A=; b=LDeDjZlTi3A86Yeiq8ncE/fKe0B1T4BmyVzmqxPbZFsg9WVNYL47o6DDSk/6QDR4OC QmnFXk4+hMy/pEQ0k+ocTH3b5ooyDvB60XqOHzb3GtXQzQgYzAXnDcaunW2qQIRrUPjz lIBv1uXB8ricVUiLsdTINHMi1JeHMhWKO6qj9a0iAw5Taq/SNRUUwasnNLrkcHY5Y/cJ p3i5nq3HVr98dvNT4Ud2SVvUB3dYLZ+q9HuzOPFfUHUfCthQx5+Y0stHx+S+JGfBp91Z fppRENW0D8BUiYIo5f5uzBd2JtqZf2gL9vI074R5GGJnVewA8IufbLa0aBc9CMxiL1Ij CZWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TeonSrKFIrS7BL6SFpjAf7TUwrVOapkDWirTh+WY03A=; b=Fuhp5glb70LL/eMBerDzU73TBLlzsoOOAK0wguJ6tVgXuty9E8knTnK32vtUcaM9oy 9hEpRcJmR46xZaWLZC41opCJYcxjOTEu9Wanh/U4nyD6cod+m5niRNPVXxCKl85zsIDw vgCaHZM2Kom2fvuCzDRTyNpRsb8oBPRVHgq4CcSfPjqBSLX0A161j+IKh/JCOAVVIMt/ a6hmHxeV6FX9urG+jmNUVY/QCAOpPWWhKsLEZSu1lOy6VNRjv7NhBFxyH9RXf+G7wT08 TvQlfuJ0SvDDGa8V3JoljyH/XFQdJHlS2ouP836lglAP0o6a8qzMKSTjxRggCLlwHGZJ 1V+Q== X-Gm-Message-State: AOAM5316aLYb7MQxGHsGbiqpGBNI9qmWY/kcSoI6mNB7Og1mvbZQ27yd 8urqeybHoo/+1ssMShHU95X0H5S8BynntuyuDlSLsg== X-Google-Smtp-Source: ABdhPJzuKkuCT0kAfItXnP46EExFfI964p8PcZjwt19KdsYxmr88Jg7H+MX8Zlw2y4mRlnlcCbcTwN4TLTcoRzdCf7M= X-Received: by 2002:a05:6402:366:: with SMTP id s6mr2230742edw.44.1607523972468; Wed, 09 Dec 2020 06:26:12 -0800 (PST) MIME-Version: 1.0 References: <20201208181554.435-1-peter.maydell@linaro.org> <20201208181554.435-2-peter.maydell@linaro.org> In-Reply-To: From: Peter Maydell Date: Wed, 9 Dec 2020 14:26:01 +0000 Message-ID: Subject: Re: [PATCH 1/4] clock: Introduce clock_ticks_to_ns() To: Richard Henderson Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::532; envelope-from=peter.maydell@linaro.org; helo=mail-ed1-x532.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Damien Hedde , Aleksandar Rikalo , QEMU Developers , Luc Michel , =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Wed, 9 Dec 2020 at 14:11, Richard Henderson wrote: > This function is truncating back to 64.0, dropping the 32 high bits and 32 low > bits. We lose bits at 2^64 ns ~= 584 years. Which is still unreasonably long, > but could still be had from a timer setting ~= never. > > An alternate to an assert could be saturation. Input "infinity", return > "infinity". More or less. Might be an idea. We have never really properly nailed down what QEMU's simulation of time does when it hits INT64_MAX nanoseconds (which is the furthest forward absolute time you can set a QEMUTimer). In particular if you use the icount sleep=on option it is actually possible for the simulation to get there (set a far-future timer, no other interrupts or simulation input, do a sleep-til-next-interrupt) and I have no idea what QEMU should do at that point (print "Welcome to the end of the universe" and exit?). FWIW, the reason I made this API take a 64-bit tick count and return a 64-bit nanosecond count is because we do have timer devices where the tick count is 64 bits (eg the Arm Generic Timers in the CPU) and the QEMUTimer APIs all want "expiry date in nanoseconds as a signed 64-bit value". thanks -- PMM