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=-15.2 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 3C1CCC6369E for ; Wed, 2 Dec 2020 22:47:59 +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 910D3208FE for ; Wed, 2 Dec 2020 22:47:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 910D3208FE Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:45332 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kkauj-0007eD-7Z for qemu-devel@archiver.kernel.org; Wed, 02 Dec 2020 17:47:57 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:55976) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kkatK-0006zT-Lr for qemu-devel@nongnu.org; Wed, 02 Dec 2020 17:46:30 -0500 Received: from mail-yb1-xb43.google.com ([2607:f8b0:4864:20::b43]:39580) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kkatI-0000aD-1J for qemu-devel@nongnu.org; Wed, 02 Dec 2020 17:46:30 -0500 Received: by mail-yb1-xb43.google.com with SMTP id g15so208007ybq.6 for ; Wed, 02 Dec 2020 14:46:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FTcuUdP5ILEVF8knhAEVcNwSryuaJ5/WbUTgQV6A0DI=; b=gtBS9xzY6iNthJT0kSJhF9NoPMo0jNlerUHSBN/EhR+Sdae2LUK1YJMLLd2PnFnvYB qG25jnIu119eiwAJNRyQutMpe4pxjN0x9Jl6PNZ3IQ9QrpcqWB54U72CJlTtrZL7PVC9 fbcPf8f8HrE7xDZPUPS4eBYje4e+NjS0MtJ5RBsj36lDCNIhk7hs6as5VDimMlP6UBjB hlYNXzZgnZU/vBACzdlPdd1jhEZoLaDkXqKmvCVGnHHGO48oM+IynQQPEMVWvaoeTKpK stOvyrMYEdvvTyEYUvWUo3v/nIYzLm32SVW2JdaVtjM7nGXrP6qbekmyqgTOqNSIZNEJ NRmQ== 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=FTcuUdP5ILEVF8knhAEVcNwSryuaJ5/WbUTgQV6A0DI=; b=DZsX+z4osxlfmZK/WjXeJJI7rh/VVU/vD9KRYo1LmoZfvbd4XwGNrl2vo2K6XB2YLy /x5FL3zjCrZ1DLddHHvnc97x6SH4nytr5QXHjUcsVjnXxLJHDkpv/95A8hGxMIOCG6r8 6kX945K5sf9OP/uE1GnGcRbRLRcNMxI5Q+bBxq3NTxTZCbihHM2hJyThoQ065yq3Z0o/ 2fYsE86ZDs6XNxp0EsESQJ29KZ6DleTt8khSN/xrUwLi8mzWIsUVUCFdWgi/iJGw3TeU IghN0QKpjOLzAIYzs+YMkoe+cf2K6FNqoUS/NZfATEdbBiwgPDC8mFemxSwKaPP6gjnE DlGA== X-Gm-Message-State: AOAM531WQtgxzOVNUKia0Z3AnwfStP9ZNU1S+fpf6dm6XICaBIIGvypW ykfnShmndPEuoEpmu+quVgaB2N8HaMMJAtdntunrjg== X-Google-Smtp-Source: ABdhPJySsowPY7zEKBD1QOk4u7ypk7tl7RZ0uso+ihNfiHEM8ButL9bOp3ZRM0PGckVAiGnmIwU1bMMtuyM66DnY3lg= X-Received: by 2002:a25:24d4:: with SMTP id k203mr673203ybk.62.1606949186741; Wed, 02 Dec 2020 14:46:26 -0800 (PST) MIME-Version: 1.0 References: <2dc974cc-abe2-d034-1720-d5a2651a9042@csgraf.de> In-Reply-To: <2dc974cc-abe2-d034-1720-d5a2651a9042@csgraf.de> From: Frank Yang Date: Wed, 2 Dec 2020 14:46:13 -0800 Message-ID: Subject: Re: [PATCH v1 1/1] hvf: arm: Properly sync guest time on migration To: Alexander Graf Cc: Peter Collingbourne , Roman Bolshakov , Peter Maydell , Eduardo Habkost , Richard Henderson , qemu-devel , Cameron Esfahani , qemu-arm , Claudio Fontana , Paolo Bonzini Content-Type: multipart/alternative; boundary="00000000000073149705b5830324" Received-SPF: pass client-ip=2607:f8b0:4864:20::b43; envelope-from=lfy@google.com; helo=mail-yb1-xb43.google.com X-Spam_score_int: -175 X-Spam_score: -17.6 X-Spam_bar: ----------------- X-Spam_report: (-17.6 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5 autolearn=unavailable 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: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --00000000000073149705b5830324 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 2, 2020 at 2:28 PM Alexander Graf wrote: > > On 02.12.20 23:19, Frank Yang wrote: > > > From downstream: > https://android-review.googlesource.com/c/platform/external/qemu/+/1515002 > > Based on v3 of Alexander Graf's patches > > https://patchew.org/QEMU/20201202190408.2041-1-agraf@csgraf.de > > We need to adjust CNTVOFF_EL2 so that time doesnt warp. Even though we > can set separate CNTVOFF_EL2 values per vCPU, it just is not worth the > require effort to do that accurately---with individual values, even if > they are a tiny bit off it can result in a lockup due to inconsistent > time differences between vCPUs. So just use a global approximate value > for now. > > Not tested in upstream yet, but Android emulator snapshots work without > time warp now. > > Signed-off-by: Lingfeng Yang > > > If we just always make CNTV start at the same 0 as QEMU_CLOCK_VIRTUAL, we > should be able to just recover the offset after migration by looking at > QEMU_CLOCK_VIRTUAL to set CNTVOFF, right? > > That would end up much easier than this patch I hope. > > > The virtual clock interfaces/implementations in QEMU seem complex to me relative to the fix needed here and they don't seem to compute ticks with mach_absolute_time() (which in this case we want since we want to compute in timer ticks instead of having to mess with ns / cycle conversions). I do agree this patch does seem more complicated on the surface though versus "just" setting cntvoff directly to some value. Maybe we should simplify the QEMU_CLOCK_VIRTUAL implementation first to maintain CNTVOFF_EL2/CNTV using mach_absolute_time() first? > Alex > > > --00000000000073149705b5830324 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 2, 2020 at 2:28 PM Alexan= der Graf <agraf@csgraf.de> wro= te:
=20 =20 =20


On 02.12.20 23:19, Frank Yang wrote:
=20

From downstream: https://android= -review.googlesource.com/c/platform/external/qemu/+/1515002

Based on v3 of Alexander Graf's patches

https://patchew.org/QEMU/20201202190408.2041-1-= agraf@csgraf.de

We need to adjust CNTVOFF_EL2 so that time doesnt warp.=C2=A0 Eve= n though we
can set separate CNTVOFF_EL2 values per vCPU, it just is not worth the
require effort to do that accurately---with individual values, even if
they are a tiny bit off it can result in a lockup due to inconsistent
time differences between vCPUs. So just use a global approximate value
for now.

Not tested in upstream yet, but Android emulator snapshots work without
time warp now.

Signed-off-by: Lingfeng Yang <lfy@google.com>


If we just always make CNTV start at the same 0 as QEMU_CLOCK_VIRTUAL, we should be able to just recover the offset after migration by looking at QEMU_CLOCK_VIRTUAL to set CNTVOFF, right?

That would end up much easier than this patch I hope.



The virtual clock inte= rfaces/implementations in QEMU seem complex to me relative to the fix neede= d here and they don't seem to compute ticks with mach_absolute_time() (= which in this case we want since we want to compute in timer ticks instead = of having to mess with ns / cycle conversions). I do agree this patch does = seem more complicated on the surface though versus "just" setting= cntvoff=C2=A0directly to some value. Maybe we should simplify the QEMU_CLO= CK_VIRTUAL implementation first to maintain CNTVOFF_EL2/CNTV using mach_abs= olute_time() first?
=

Alex


--00000000000073149705b5830324--