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=-4.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 B65D8C4727C for ; Tue, 29 Sep 2020 15:29:42 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 1A16A20773 for ; Tue, 29 Sep 2020 15:29:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="xg4NKY7y"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="qebXSOEK" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1A16A20773 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=64z6cc1wMF/dIH7WGmmD3e+zVy6i1Cz5bel2rN9Hrmw=; b=xg4NKY7y5xhHcFjHO9rz308hw eucF02kqz9ieyMbkqPVf32szoRkMOdFn8uj3kSl/SXOr0w81F2Cj5JjYB8c/AuY/RZpstJVzJrkDA CEvpeIDGc7FTrg83q1sWU2Va7VHLf6qDenUhXPiwFg+WZGttvFOh0JGGizznSHnvMm8/0gn+EW5Vz h7qXvJMYIEDL1AZy/WCB8Q9ptOUU6zcapGqpDJc3wgmpBSQy7dqC3qAqiB+voq/qsPVm1zkffGMEK 6alSXlo7gEBJdhBdtLOUKjDPNZGFsyvNL7SbKdr47mwkDTnCRpS0gZrfCrj0UNdofIbDoR6iagrGS dJASoXsVA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kNHXl-0002He-57; Tue, 29 Sep 2020 15:27:53 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kNHXh-0002GN-Ds for linux-arm-kernel@lists.infradead.org; Tue, 29 Sep 2020 15:27:50 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D3A15207F7; Tue, 29 Sep 2020 15:27:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601393268; bh=i5XygYKUbhjc8E7QHK8mBozTXBb67C6QTVJ1UnIiG+Y=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=qebXSOEKVQP7sAM/WeZKDV0h0M+ThqhsZpd2dxoZ5S+QiYYN0W5P1KjkWWawU+Eqm 92HcIL4waMmBaLPDiYFFgLQSK3SaHjNGukYxY833e/xLElEaMKGabwNonYG/mB2eVu i4ERqRrGhRegCe/43k2019Q8aETP7xDt5EyMvisQ= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kNHXd-00Fsvn-Rl; Tue, 29 Sep 2020 16:27:45 +0100 MIME-Version: 1.0 Date: Tue, 29 Sep 2020 16:27:45 +0100 From: Marc Zyngier To: Lorenzo Pieralisi Subject: Re: [PATCH 22/23] KVM: arm64: Add a rVIC/rVID in-kernel implementation In-Reply-To: <20200929151354.GA4877@e121166-lin.cambridge.arm.com> References: <20200903152610.1078827-1-maz@kernel.org> <20200903152610.1078827-23-maz@kernel.org> <20200929151354.GA4877@e121166-lin.cambridge.arm.com> User-Agent: Roundcube Webmail/1.4.8 Message-ID: <136948b6e93db336b8a87e8f16335e7c@kernel.org> X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: lorenzo.pieralisi@arm.com, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, kernel-team@android.com, Christoffer.Dall@arm.com, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200929_112749_629936_C7F979BE X-CRM114-Status: GOOD ( 22.27 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kvm@vger.kernel.org, Suzuki K Poulose , Christoffer Dall , James Morse , Julien Thierry , kernel-team@android.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Lorenzo, On 2020-09-29 16:13, Lorenzo Pieralisi wrote: > On Thu, Sep 03, 2020 at 04:26:09PM +0100, Marc Zyngier wrote: > > [...] > >> +static void __rvic_sync_hcr(struct kvm_vcpu *vcpu, struct rvic *rvic, >> + bool was_signaling) >> +{ >> + struct kvm_vcpu *target = kvm_rvic_to_vcpu(rvic); >> + bool signal = __rvic_can_signal(rvic); >> + >> + /* We're hitting our own rVIC: update HCR_VI locally */ >> + if (vcpu == target) { >> + if (signal) >> + *vcpu_hcr(vcpu) |= HCR_VI; >> + else >> + *vcpu_hcr(vcpu) &= ~HCR_VI; >> + >> + return; >> + } >> + >> + /* >> + * Remote rVIC case: >> + * >> + * We kick even if the interrupt disappears, as ISR_EL1.I must >> + * always reflect the state of the rVIC. This forces a reload >> + * of the vcpu state, making it consistent. > > Forgive me the question but this is unclear to me. IIUC here we do > _not_ > want to change the target_vcpu.hcr and we force a kick to make sure it > syncs the hcr (so the rvic) state on its own upon exit. Is that correct > ? This is indeed correct. Changing the vcpu's hcr is racy as we sometimes update it on vcpu exit, so directly updating this field would require introducing atomic accesses between El1 and EL2. Not happening. Instead, we force the vcpu to reload its own state as it *reenters* the guest (and not on exit). This way, no locking, no cmpxchg, everything is still single threaded. > Furthermore, I think it would be extremely useful to elaborate (ie > rework the comment) further on ISR_EL1.I and how it is linked to this > code path - I think it is key to understanding it. I'm not really sure what to add here, apart from paraphrasing the ARM ARM. ISR_EL1 always represents the interrupt input to the CPU, virtual or not, and we must honor this requirements by making any change of output of the rVIC directly observable (i.e. update HCR_EL2.VI). M. -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel