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=-3.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,FSL_HELO_FAKE,HEADER_FROM_DIFFERENT_DOMAINS, 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 CCDA9C07E9B for ; Wed, 21 Jul 2021 08:49:31 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 97B006108B for ; Wed, 21 Jul 2021 08:49:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 97B006108B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.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=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=5bPQIwAmIexk+CjA6wEuqSOSVEM+OCFjmnCvOi+GODQ=; b=LGSbY/hgllv/DO WUADZ7D/4SbPVq+kaWMOOHS4d4XWBEH8M6HCmcngMdcEyjJvDxK2IWhHmFifOKzYYro9m5/E+pthQ 8mx72dHibt1i1QqDwdgtcpw6VgRS1BJrxWHJ233scM2XWOwXfuiE498SZVeWT2I62gD0yKui8Redl EsuDw6RvK7lYOtDl2d/MXnbJoyvle9dDcfDdh3tKXbAL4oiaPD/e2MrdgJIuX4n6D/Qo9rq7C2ANV yMlWZmOqCheF12cQRkckiGLGZxbW5oIeu0xoBnk74Lmdh+UeHfV5Zaz+8LYQn8dGp2onQ3pZOOOeM AtHPkKVRJ7c9OuluIEpg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m67tb-00EzX5-K8; Wed, 21 Jul 2021 08:48:03 +0000 Received: from mail-pg1-x52a.google.com ([2607:f8b0:4864:20::52a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1m67tX-00EzWY-Hp for linux-arm-kernel@lists.infradead.org; Wed, 21 Jul 2021 08:48:01 +0000 Received: by mail-pg1-x52a.google.com with SMTP id t9so1228601pgn.4 for ; Wed, 21 Jul 2021 01:47:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=FQYxugu8t7vqF745nuDd0P6UH3tWWI/YKaDa8xctYR4=; b=XU4l682naheW6tuKnH+MytrNWxbdp9Yxn32GC8utg8SR/VPsrXfeSXRbqRr2ldZE4B agGAumGKQbhn9UkIWNjFal/Uww+gAiAZu8Z3sjcQXOJaizdwTd05HLwGTXLiYmvvKoEM khZ1dzPT0dikZFlNKTmeXUrCafw53Wxs2a5eU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=FQYxugu8t7vqF745nuDd0P6UH3tWWI/YKaDa8xctYR4=; b=AAHTvccKcWJf28wvLAriT6n2T9mZw3qaQ67RVmr4EkwPet24827brwqdf9E4QNd/U8 ffzKiV6+v9Wg+rhbfSSZUL95FTIB7Gi6BJJRSTp9QSQxuQMfSmboOHf6HUG5sNCmEl9E jXraiKiZCC350edIEksSAw2SCeSg603LyGn70xKhU5LLeFn/Caf4i3+0Yq0i8NmYy053 4s4DMTErlR7a2XyWJpqTr3TSQsOESoE++A1SkWqqGzDbH9+sLtsWU1GxGxHeVrd0hzwI xAUV3EMlYZd9zajtvPfVDDfFcoqqY+I5/BKEV1rbBoD3pjKc97KbxjijX31m//VY31Ls 5MCQ== X-Gm-Message-State: AOAM530OZ+MZTQVAsyhAWXfGKVSNdeFJunSlbyJJPO6PfAdtKe01H+Yz hQnZj9/4puA2M2iBcFSSt47tHA== X-Google-Smtp-Source: ABdhPJx2D4LSvi7V3G0rkeLs5yU/EesBkZYFpPqRMSteyEvOP3OhnjDDojnYkSbfYTT48DGn/kEOHg== X-Received: by 2002:a63:4f21:: with SMTP id d33mr3274287pgb.144.1626857278147; Wed, 21 Jul 2021 01:47:58 -0700 (PDT) Received: from google.com ([2409:10:2e40:5100:f1b2:269f:996b:b71a]) by smtp.gmail.com with ESMTPSA id b10sm25785133pfi.122.2021.07.21.01.47.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Jul 2021 01:47:57 -0700 (PDT) Date: Wed, 21 Jul 2021 17:47:52 +0900 From: Sergey Senozhatsky To: Marc Zyngier Cc: Sergey Senozhatsky , 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 Message-ID: References: <20210709043713.887098-1-senozhatsky@chromium.org> <20210709043713.887098-3-senozhatsky@chromium.org> <877dhv35ea.wl-maz@kernel.org> <87im142i0b.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87im142i0b.wl-maz@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210721_014759_652403_3BCF840A X-CRM114-Status: GOOD ( 21.26 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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. 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? > 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. > How does it work across reset? I need to figure out what happens during reset/migration in the first place. > I'm sorry to be that pressing, but these are the gory details that > actually matter if you want this thing to be maintainable. Sure, no problem. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel