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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EAFCBC433F5 for ; Thu, 3 Mar 2022 17:51:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231147AbiCCRw3 (ORCPT ); Thu, 3 Mar 2022 12:52:29 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47712 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229496AbiCCRw2 (ORCPT ); Thu, 3 Mar 2022 12:52:28 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B149C1A1C6B for ; Thu, 3 Mar 2022 09:51:42 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id F268AB82667 for ; Thu, 3 Mar 2022 17:51:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A14C9C004E1; Thu, 3 Mar 2022 17:51:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646329899; bh=dS8pMhjLnWoEzsoILwriRJWHNTv/UK4gumZtJEsJZdQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=izdKrdS6Tg7paJZCLlUxDtzHw81gnt4v+yXNck2imlQpz1tY136Ij2xRnQ5Sxs8JD HQ7BlG0NDPa7n7nsddR4OCwe+PzdMgJelHwL0BtCXOblnMsdKcx4m/10KOCrqBaSBF ylscHBZiyjr176HxKoMO4KylAbcxwzryYDhvNUqoGn8WjQWvWYChDMHkvtKR+vw2gS Yb0ngOMwDmVGP28HIa+NKWEzUwyqlo7XfZywHcThWELLK9EFs5vB5TILkZRbZ0iVWF tfS7opsXfnuWDnwmKec8ziwQjU7IokVnw3zDgYN4oSw4s2ZWYiaNhMuahWHAIZ30vt wNFQlKdbtf4eQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nPpc1-00C1Wj-7A; Thu, 03 Mar 2022 17:51:37 +0000 Date: Thu, 03 Mar 2022 17:51:36 +0000 Message-ID: <87pmn22ac7.wl-maz@kernel.org> From: Marc Zyngier To: Sebastian Ene Cc: kvm@vger.kernel.org, qperret@google.com, will@kernel.org, julien.thierry.kdev@gmail.com Subject: Re: [PATCH kvmtool v7 2/3] aarch64: Add stolen time support In-Reply-To: References: <20220302140734.1015958-1-sebastianene@google.com> <20220302140734.1015958-3-sebastianene@google.com> <8735k02z98.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: sebastianene@google.com, kvm@vger.kernel.org, qperret@google.com, will@kernel.org, julien.thierry.kdev@gmail.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Thu, 03 Mar 2022 12:01:10 +0000, Sebastian Ene wrote: > > > > +int kvm_cpu__setup_pvtime(struct kvm_cpu *vcpu) > > > +{ > > > + int ret; > > > + bool has_stolen_time; > > > + u64 pvtime_guest_addr = ARM_PVTIME_MMIO_BASE + vcpu->cpu_id * > > > + ARM_PVTIME_STRUCT_SIZE; > > > + struct kvm_config *kvm_cfg = NULL; > > > + struct kvm_device_attr pvtime_attr = (struct kvm_device_attr) { > > > + .group = KVM_ARM_VCPU_PVTIME_CTRL, > > > + .addr = KVM_ARM_VCPU_PVTIME_IPA > > > + }; > > > + > > > + kvm_cfg = &vcpu->kvm->cfg; > > > + if (kvm_cfg->no_pvtime) > > > + return 0; > > > + > > > + if (!pvtime_data.is_supported) > > > + return -ENOTSUP; > > > > It is a bit odd to have this hard failure if running on a system that > > doesn't have pvtime. It forces the user to alter their command-line, > > which is a bit annoying. I'd rather have a soft-fail here. > > > > The flag 'is_supported' is set to false when we support pvtime but we > fail to configure it. We verify that we support pvtime by calling the check > extension KVM_CAP_STEAL_TIME. I think the naming is odd here for the > flag name. It should be : 'is_failed_cfg'. Ah, I see. Yes, the name is misleading. > > > > + > > > + has_stolen_time = kvm__supports_extension(vcpu->kvm, > > > + KVM_CAP_STEAL_TIME); > > > + if (!has_stolen_time) > > > + return 0; Here, you could force no_pvtime to 1, and avoid checking for each vcpu once you detected that the host is not equipped to deal with it. Thanks, M. -- Without deviation from the norm, progress is not possible.