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=-5.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 E246EC07E95 for ; Mon, 19 Jul 2021 18:03:49 +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 AC20560FF3 for ; Mon, 19 Jul 2021 18:03:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AC20560FF3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.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=22bJq9MGVg1AWAGUaRz9UVDrs/i5ENM2w+rzp6nB3eg=; b=V2sf6zxMQU7g6s zzO71gVG140iwVLcLIUjGszEhYLFq6Fn8mjmxlLtyEkPs4FDUlph2wAvBw2rehzYifUDw0I8ii+yB EQpADz3Q/tWJqqb5W3oKRObiW33O2ynMdpumcQFZNbIileeo2wTTS15/weH3sZRBon0iWNY6gZeBI v4fz6j3411gHRYr1N6w16bbjnIrOWuMRXXzAYSO1Sx/i3ICGS8kaUNAGraXlvzbPuvBq5VTp28haa TAty3U7NijpUJMxqn1oeVo2pBlJaeEQCr4LSFnulzO3ALqWcr9PMTFkPx6Cw4yfSz4rHbwHjUsT42 Wp/Hpe0fOC/GjjXlevoA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m5Xb9-00AqGc-Rf; Mon, 19 Jul 2021 18:02:36 +0000 Received: from mail-ed1-x536.google.com ([2a00:1450:4864:20::536]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1m5Xb6-00AqFS-3M for linux-arm-kernel@lists.infradead.org; Mon, 19 Jul 2021 18:02:33 +0000 Received: by mail-ed1-x536.google.com with SMTP id h8so25220899eds.4 for ; Mon, 19 Jul 2021 11:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=iwY647XqSBr0nhop6u+nJOZDJO2ojgmzAbMlPyzAP2A=; b=de4dSCIFeNoXczBGIJKhs+9cQ67ihAH384iDNj7/ghw8A521i45BAOlb9Wj5VrML2B ts5bNRNWddT+aI1DLJIMor+SL4/f3zNwEtrLVZsD2tjcjsRkzEr1TRxdDN0DwJUJ6pq2 vSViocJn6F9z759rRSS8/3I8kikyFNECOd2Jum/ADid6KfFaxXYT7kzrn3v/uD/drMMG QmB7VB6/FnvNvlUQU1yQ7RgVec5cXCMQW4i7ue70iiKVBvUrwW3xqoF7vRTo45xa+TQV ER89LXFuY7yD0DDbzZMfbrV5Of00o5bIHTQbJFYMZNcVBnBX+yL0g9CKq1SafiocuodB XvpA== 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=iwY647XqSBr0nhop6u+nJOZDJO2ojgmzAbMlPyzAP2A=; b=SWhcvvuW0HLYrmWAT0IL7A0ADqb02ODhm+Ks3W6/h00GEL3o1EyGfd1VPL475ugfpY Em/LwF632bWfkvYIhGdbjCzGCcrEPDthU/KWpyTr3T8zf4P4uJm7K4d7FFEk0KCRts6t VejJM4yswyA5Hea948ViDJtAU3ypZNn3dpX5EvU6pH0Ep9IyxZ+sNRoq1TcD2+DHAXq3 ah+PmIWqhBhMNP/s+hzpPfgIS3n8lxmIGhp/Di1bIfJ/CV4oyGFdRoUuN4xhy7Zjoax0 8xNkSIsZVEdhmsTGouNtPtYk3jgcyqn6VRstOkdxvr72qIhDxSrTw9IX/1gT3wQOPSVu l09g== X-Gm-Message-State: AOAM532MueYHJ33FKX2GJVom73LhW7yNkJxekZSWuXQObq1TQLe2e2G8 RWRUPZnpCU1PZCh/Wrjarm/b9g== X-Google-Smtp-Source: ABdhPJyQlO0WF1yuY/72pvxqzE/S/j0RUDWpsZG3FB/CGPHlXlZjXIrduqfJdRb/baD0ksNgkAUGWw== X-Received: by 2002:a05:6402:1592:: with SMTP id c18mr35924631edv.243.1626717749925; Mon, 19 Jul 2021 11:02:29 -0700 (PDT) Received: from myrica (adsl-84-226-111-173.adslplus.ch. [84.226.111.173]) by smtp.gmail.com with ESMTPSA id n14sm8178314edo.23.2021.07.19.11.02.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Jul 2021 11:02:29 -0700 (PDT) Date: Mon, 19 Jul 2021 20:02:06 +0200 From: Jean-Philippe Brucker To: Alexandru Elisei Cc: maz@kernel.org, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, pbonzini@redhat.com, corbet@lwn.net, james.morse@arm.com, suzuki.poulose@arm.com, catalin.marinas@arm.com, will@kernel.org, lorenzo.pieralisi@arm.com, salil.mehta@huawei.com, shameerali.kolothum.thodi@huawei.com, jonathan.cameron@huawei.com Subject: Re: [RFC PATCH 0/5] KVM: arm64: Pass PSCI to userspace Message-ID: References: <20210608154805.216869-1-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-20210719_110232_221358_8818C215 X-CRM114-Status: GOOD ( 33.21 ) 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 Hi Alex, I'm not planning to resend this work at the moment, because it looks like vcpu hot-add will go a different way so I don't have a user. But I'll probably address the feedback so far and park it on some branch, in case anyone else needs it. On Mon, Jul 19, 2021 at 04:29:18PM +0100, Alexandru Elisei wrote: > 1. Why forwarding PSCI calls to userspace depend on enabling forwarding for other > HVC calls? As I understand from the patches, those handle distinct function IDs. The HVC cap from patch 4 enables returning from the VCPU_RUN ioctl with KVM_EXIT_HYPERCALL, for any HVC not handled by KVM. This one should definitely be improved, either by letting userspace choose the ranges of HVC it wants, or at least by reporting ranges reserved by KVM to userspace. The PSCI cap from patch 5 disables the in-kernel PSCI implementation. As a result those HVCs are forwarded to userspace. It was suggested that other users will want to handle HVC calls (SDEI for example [1]), hence splitting into two capabilities rather than just the PSCI cap. In v5.14 x86 added KVM_CAP_EXIT_HYPERCALL [2], which lets userspace receive specific hypercalls. We could reuse that and have PSCI be one bit of that capability's parameter. [1] https://lore.kernel.org/linux-arm-kernel/20170808164616.25949-12-james.morse@arm.com/ [2] https://lore.kernel.org/kvm/90778988e1ee01926ff9cac447aacb745f954c8c.1623174621.git.ashish.kalra@amd.com/ > 2. HVC call forwarding to userspace also forwards PSCI functions which are defined > in ARM DEN 0022D, but not (yet) implemented by KVM. What happens if KVM's PSCI > implementation gets support for one of those functions? How does userspace know > that now it also needs to enable PSCI call forwarding to be able to handle that > function? We forward the whole PSCI function range, so it's either KVM or userspace. If KVM manages PSCI and the guest calls an unimplemented function, that returns directly to the guest without going to userspace. The concern is valid for any other range, though. If userspace enables the HVC cap it receives function calls that at some point KVM might need to handle itself. So we need some negotiation between user and KVM about the specific HVC ranges that userspace can and will handle. > It looks to me like the boundary between the functions that are forwarded when HVC > call forwarding is enabled and the functions that are forwarded when PSCI call > forwarding is enabled is based on what Linux v5.13 handles. Have you considered > choosing this boundary based on something less arbitrary, like the function types > specified in ARM DEN 0028C, table 2-1? For PSCI I've used the range 0-0x1f as the boundary, which is reserved for PSCI by SMCCC (table 6-4 in that document). > > In my opinion, setting the MP state to HALTED looks like a sensible approach to > implementing PSCI_SUSPEND. I'll take a closer look at the patches after I get a > better understanding about what is going on. > > On 6/8/21 4:48 PM, Jean-Philippe Brucker wrote: > > Allow userspace to request handling PSCI calls from guests. Our goal is > > to enable a vCPU hot-add solution for Arm where the VMM presents > > possible resources to the guest at boot, and controls which vCPUs can be > > brought up by allowing or denying PSCI CPU_ON calls. Passing HVC and > > PSCI to userspace has been discussed on the list in the context of vCPU > > hot-add [1,2] but it can also be useful for implementing other SMCCC and > > vendor hypercalls [3,4,5]. > > > > Patches 1-3 allow userspace to request WFI to be executed in KVM. That > > I don't understand this. KVM, in kvm_vcpu_block(), does not execute an WFI. > PSCI_SUSPEND is documented as being indistinguishable from an WFI from the guest's > point of view, but it's implementation is not architecturally defined. Yes that was an oversimplification on my part Thanks, Jean _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel