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.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 AE37BC07E9B for ; Wed, 21 Jul 2021 10:28:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 851BE60FF2 for ; Wed, 21 Jul 2021 10:28:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239124AbhGUJp5 (ORCPT ); Wed, 21 Jul 2021 05:45:57 -0400 Received: from mail.kernel.org ([198.145.29.99]:51436 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238806AbhGUJf1 (ORCPT ); Wed, 21 Jul 2021 05:35:27 -0400 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 AC1CD61222; Wed, 21 Jul 2021 10:16:04 +0000 (UTC) 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 1m69Gk-00EgEK-O6; Wed, 21 Jul 2021 11:16:02 +0100 Date: Wed, 21 Jul 2021 11:16:02 +0100 Message-ID: <87bl6w2crh.wl-maz@kernel.org> From: Marc Zyngier To: Sergey Senozhatsky Cc: Will Deacon , Suleiman Souhlal , Joel Fernandes , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org Subject: Re: [PATCHv2 2/4] arm64: add guest pvstate support In-Reply-To: References: <20210709043713.887098-1-senozhatsky@chromium.org> <20210709043713.887098-3-senozhatsky@chromium.org> <877dhv35ea.wl-maz@kernel.org> <87im142i0b.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: senozhatsky@chromium.org, will@kernel.org, suleiman@google.com, joelaf@google.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org 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: linux-kernel@vger.kernel.org On Wed, 21 Jul 2021 09:47:52 +0100, Sergey Senozhatsky wrote: > > On (21/07/21 09:22), Marc Zyngier wrote: > > On Wed, 21 Jul 2021 03:05:25 +0100, > > Sergey Senozhatsky wrote: > > > > > > On (21/07/12 16:42), Marc Zyngier wrote: > > > > > > > > > > PV-vcpu-state is a per-CPU struct, which, for the time being, > > > > > holds boolean `preempted' vCPU state. During the startup, > > > > > given that host supports PV-state, each guest vCPU sends > > > > > a pointer to its per-CPU variable to the host as a payload > > > > > > > > What is the expected memory type for this memory region? What is its > > > > life cycle? Where is it allocated from? > > > > > > Guest per-CPU area, which physical addresses is shared with the > > > host. > > > > Again: what are the memory types you expect this to be used with? > > I heard your questions, I'm trying to figure out the answers now. > > As of memory type - I presume you are talking about coherent vs > non-coherent memory. No. I'm talking about cacheable vs non-cacheable. The ARM architecture is always coherent for memory that is inner-shareable, which applies to any system running Linux. On the other hand, there is no architected cache snooping when using non-cacheable accesses. > Can guest per-CPU memory be non-coherent? Guest never writes > anything to the region of memory it shares with the host, it only > reads what the host writes to it. All reads and writes are done from > CPU (no devices DMA access, etc). > > Do we need any cache flushes/syncs in this case? If you expect the guest to have non-cacheable mappings (or to run with its MMU off at any point, which amounts to the same thing) *and* still be able to access the shared page, then *someone* will have to perform CMOs to make these writes visible to the PoC (unless you have FWB). Needless to say, this would kill any sort of performance gain this feature could hypothetically bring. Defining the scope for the access would help mitigating this, even if that's just a sentence saying "the shared page *must* be accessed from a cacheable mapping". > > > When will the hypervisor ever stop accessing this? > > KVM always access it for the vcpus that are getting scheduled out or > scheduled in on the host side. I was more hinting at whether there was a way to disable this at runtime. Think of a guest using kexec, for example, where you really don't want the hypervisor to start messing with memory that has been since reallocated by the guest. > > How does it work across reset? > > I need to figure out what happens during reset/migration in the first > place. Yup. M. -- Without deviation from the norm, progress is not possible.