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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 73756C636D4 for ; Fri, 10 Feb 2023 19:24:39 +0000 (UTC) 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=DvdKvE4zmera6y7tuvKWssuKmblwhopy4+o3fz7HC18=; b=EnEtVsJZLlyW9I abAJ/SCov2MPiNU5oXybvBjtCNV4fZE2p8mpmH0lf3R8tVJrKSFbIYQVuUZ6nre6sqm4eeAlw8WRo sN5R/9Q4LQ4CEQn9t682jqEWPxzlMxllJi8NsdjBftGlWboQx5Nm4sbqw8QIA5CQXjTW7amYjW6cF U200Qo1OK69Mxx0JoHGPbpZ47S7jNx+5GQ28nYMo8t2NyZwzlx1eOQwOzhnidLccfO1F12JdYrvm9 ZaAomAjUj0uFSvXlv277DeucgDtXznOiOIVIWUPmHrzn8TNDkp2H9mJIUX+RSF95V1NReNKdCi2l6 1PV8upGO1tAMug4kkrjw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pQYzo-0074z8-Gb; Fri, 10 Feb 2023 19:23:44 +0000 Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pQYzl-0074xz-IX for linux-arm-kernel@lists.infradead.org; Fri, 10 Feb 2023 19:23:42 +0000 Received: by mail-wm1-x32c.google.com with SMTP id bg26so4589927wmb.0 for ; Fri, 10 Feb 2023 11:23:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=lKfwFWPx0mrSaDUSu+IwD5rq4TMnBt0i+kbnmd2g5/o=; b=fKOFy+nxE2mxy+0q4b3+SYDPuE4uFMODmK1JmAKI2/Nk498QHkmjMLG1xKbT7lDMxU WxcT2uc8nwtbsNxkhcXQVlLpZp0tcmKK5G/FTqSxr2bvnq5hQ4xMDcqr+5DbHOJgw0ZC pCtBxHz1JGtDBnaEJ0GBulsNhJnI7n1DeEBu0LNBbum2CAZofI7qLbdfQj5LbJaw+zdo HQcsF8FWmO7quEzsA9FWhKm9A7Bci4VWehUxYVx4zwBebKmZusFljhmFD+Xj1YE+wpnQ W+SaLU+E8mh9Tg98ERLKvg9bOS974FB7MNZtL/IYLRoPbv5uM2K2qAKApcQq6An4KCa6 wAWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=lKfwFWPx0mrSaDUSu+IwD5rq4TMnBt0i+kbnmd2g5/o=; b=LmDP/aMHNAc5h/5iwSRzyvUudmZ84MX7bPr65nlTjXA+d8NijCMk7uYnQ2OKxIKEkJ 3TZZIRKh8b3tLbsYRHZU4OxsvrjxhBFzuPHsvrOYyTgw2qntIkrDoIC8roRGShxbX6RV QhuMb+4whXSR3fhN6nt56UT/GeGBJLKgJP0PBNskPOJlF81mv1IixGwZ9MBmxoJnXnEJ URik7EzllF2cFrwbXeCbJwfsRnKrFhD6ox6Fu0NtUWd78gOgmjkwPiS2tawkO03dacM/ dPICsEhkL8biiks5w++7LSmUoyOwFv2FGZ1lNCmjqCmAuhVCa94d0hvCB7DaJtfdwOqv Zf9g== X-Gm-Message-State: AO0yUKV7cnM5Ez9RdjOdpoiJ5+h2CV5MgT88RtH0fegKp3pnIMr4BmDg X0CKAqcvTFgy7230PG0cHl5bNg== X-Google-Smtp-Source: AK7set/tV2rdWgmvhNxuUBbH5Kp+VjGk9gubEi8GFZRRtNk7BxFlPuMUDMhx4sndvqkKHAXXt1J4sw== X-Received: by 2002:a05:600c:b58:b0:3df:e752:35ca with SMTP id k24-20020a05600c0b5800b003dfe75235camr17613840wmr.32.1676057017763; Fri, 10 Feb 2023 11:23:37 -0800 (PST) Received: from myrica (054592b0.skybroadband.com. [5.69.146.176]) by smtp.gmail.com with ESMTPSA id t15-20020a05600c198f00b003ddc781b1d4sm6466877wmq.33.2023.02.10.11.23.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Feb 2023 11:23:37 -0800 (PST) Date: Fri, 10 Feb 2023 19:23:29 +0000 From: Jean-Philippe Brucker To: Mostafa Saleh Cc: maz@kernel.org, catalin.marinas@arm.com, will@kernel.org, joro@8bytes.org, robin.murphy@arm.com, james.morse@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, yuzenghui@huawei.com, dbrazdil@google.com, ryan.roberts@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, iommu@lists.linux.dev Subject: Re: [RFC PATCH 42/45] KVM: arm64: pkvm: Support SCMI power domain Message-ID: References: <20230201125328.2186498-1-jean-philippe@linaro.org> <20230201125328.2186498-43-jean-philippe@linaro.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230210_112341_655123_6F6EE426 X-CRM114-Status: GOOD ( 21.24 ) 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 Tue, Feb 07, 2023 at 01:27:17PM +0000, Mostafa Saleh wrote: > Hi Jean, > > > +bool kvm_host_scmi_handler(struct kvm_cpu_context *host_ctxt) > > +{ > > + DECLARE_REG(u64, func_id, host_ctxt, 0); > > + > > + if (!scmi_channel.shmem || func_id != scmi_channel.smc_id) > > + return false; /* Unhandled */ > > + > > + /* > > + * Prevent the host from modifying the request while it is in flight. > > + * One page is enough, SCMI messages are smaller than that. > > + * > > + * FIXME: the host is allowed to poll the shmem while the request is in > > + * flight, or read shmem when receiving the SCMI interrupt. Although > > + * it's unlikely with the SMC-based transport, this too requires some > > + * tightening in the spec. > > + */ > > + if (WARN_ON(__pkvm_host_add_remove_page(scmi_channel.shmem_pfn, true))) > > + return true; > > + > > + __kvm_host_scmi_handler(host_ctxt); > > + > > + WARN_ON(__pkvm_host_add_remove_page(scmi_channel.shmem_pfn, false)); > > + return true; /* Handled */ > > +} > > I am not sure what a typical SCMI channel shmem_size would be. shmem_size is large but a SCMI message isn't bigger than 128 bytes at the moment, so copying would certainly be more performant. > But would map/unmap be more performant than > memcpy(hyp_local_copy,scmi_channel.pfn,scmi_channel.shmem_size ); ? The problem is that we're forwarding this to the SCMI server, which expects to find the command in the shmem. I took the easy route here, but a more efficient way to support SCMI would be for the hypervisor to own the channel permanently, and the host<->hyp communication would use a separate shared page. The hypervisor could then copy from one channel to the other. It requires more support in the host driver so I'd like to see if there is any interest in supporting SCMI before working on this. Thanks, Jean _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel