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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 C92DCC433C1 for ; Sun, 21 Mar 2021 16:30:37 +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 C79C361937 for ; Sun, 21 Mar 2021 16:30:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C79C361937 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=csgraf.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:44160 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lO0yJ-0003UL-Jw for qemu-devel@archiver.kernel.org; Sun, 21 Mar 2021 12:30:35 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:48400) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lO0wl-0002kF-J6; Sun, 21 Mar 2021 12:28:59 -0400 Received: from mail.csgraf.de ([85.25.223.15]:53562 helo=zulu616.server4you.de) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lO0wj-0007C6-DG; Sun, 21 Mar 2021 12:28:59 -0400 Received: from Alexanders-Mac-mini.local (ec2-3-122-114-9.eu-central-1.compute.amazonaws.com [3.122.114.9]) by csgraf.de (Postfix) with UTF8SMTPSA id 4C69E6080612; Sun, 21 Mar 2021 17:28:49 +0100 (CET) Message-ID: Date: Sun, 21 Mar 2021 17:28:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:87.0) Gecko/20100101 Thunderbird/87.0 Subject: Re: [PATCH v6 09/11] arm/hvf: Add a WFI handler Content-Language: en-US To: Peter Maydell , Peter Collingbourne References: <20210120224444.71840-1-agraf@csgraf.de> <20210120224444.71840-10-agraf@csgraf.de> From: Alexander Graf In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=85.25.223.15; envelope-from=agraf@csgraf.de; helo=zulu616.server4you.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.001, 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: Eduardo Habkost , Richard Henderson , QEMU Developers , Cameron Esfahani , Roman Bolshakov , qemu-arm , Frank Yang , Paolo Bonzini Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 10.02.21 23:17, Peter Maydell wrote: > On Wed, 10 Feb 2021 at 20:25, Peter Collingbourne wrote: >> On Thu, Jan 28, 2021 at 8:25 AM Peter Maydell wrote: >>> On Wed, 20 Jan 2021 at 22:44, Alexander Graf wrote: >>>> + if (!seconds && nanos < 2000000) { >>>> + break; >>>> + } >>>> + >>>> + struct timespec ts = { seconds, nanos }; >>>> + hvf_wait_for_ipi(cpu, &ts); >>>> + } >>> Why doesn't the timer timeout manifest as an IPI ? (Put another way, >>> why is the timer interrupt special?) >> Timer timeouts result in an IPI (via HV_EXIT_REASON_VTIMER_ACTIVATED) >> if they become due while in hv_vcpu_run(). But at this point we are >> not in hv_vcpu_run() (due to the aforementioned difference in wait >> behavior between x86 and ARM) so we need to "manually" wait for the >> timer to become due, re-enter the guest, let it exit with >> HV_EXIT_REASON_VTIMER_ACTIVATED and then trigger the IPI. > But WFI doesn't just wait for a timer interrupt, it waits for > any interrupt. So it doesn't seem right that the timer interrupt > in particular is being handled specially here. It waits for either an external interrupt (vcpu_kick() -> IPI -> signal -> pselect exits) or a vtimer (kept in the CPU thread, handled by hvf natively when vCPU is running, handled through the pselect timeout when in WFI mode). In hvf on ARM, the vtimer is handled specially. It is owned by the kernel code when we're inside the CPU loop. We don't even get vtimer MSR exits. However when user space decides to not return to the kernel CPU loop, it needs to handle the vtimer expiry itself. We really only have that case on WFI. Alex