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.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,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 C2112C433E0 for ; Thu, 11 Feb 2021 00:34:41 +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 524A064E6B for ; Thu, 11 Feb 2021 00:34:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 524A064E6B 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]:46316 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l9zwO-0007CW-DE for qemu-devel@archiver.kernel.org; Wed, 10 Feb 2021 19:34:40 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:33142) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l9zvU-0006eT-5a; Wed, 10 Feb 2021 19:33:44 -0500 Received: from mail.csgraf.de ([85.25.223.15]:40582 helo=zulu616.server4you.de) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l9zvG-0002W7-M4; Wed, 10 Feb 2021 19:33:43 -0500 Received: from Alexanders-Mac-mini.local (unknown [188.138.100.120]) by csgraf.de (Postfix) with UTF8SMTPSA id BF83160803CF; Thu, 11 Feb 2021 01:33:25 +0100 (CET) Message-ID: Date: Thu, 11 Feb 2021 01:33:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:86.0) Gecko/20100101 Thunderbird/86.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: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.211, 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. The vtimer is handled by hvf itself and results in a #vmexit when triggered. On wfi, we're switching from an hvf owned vtimer to a QEMU owned one. The only events that can happen to wake us from wfi are kicks (IRQs, maintenance events) or expiry of the vtimer. The select() logic in this patch handles both, as it wakes up on an IPI (kick because of IRQ/maint event) and exits gracefully after the timer deadline. Alex