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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id ECC92C7EE2F for ; Fri, 3 Mar 2023 12:19:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231224AbjCCMTz (ORCPT ); Fri, 3 Mar 2023 07:19:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38902 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229747AbjCCMTx (ORCPT ); Fri, 3 Mar 2023 07:19:53 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id EAA1C360A8; Fri, 3 Mar 2023 04:19:51 -0800 (PST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C2FE42F4; Fri, 3 Mar 2023 04:20:34 -0800 (PST) Received: from [10.57.90.45] (unknown [10.57.90.45]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A77B93F93E; Fri, 3 Mar 2023 04:19:47 -0800 (PST) Message-ID: <2418536c-2658-18d6-f70c-c1af5adaa816@arm.com> Date: Fri, 3 Mar 2023 12:19:46 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Subject: Re: [RFC] Support for Arm CCA VMs on Linux To: Andrew Jones , Jean-Philippe Brucker Cc: Jean-Philippe Brucker , Itaru Kitayama , linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, Alexandru Elisei , Catalin Marinas , Chao Peng , Christoffer Dall , Fuad Tabba , James Morse , Joey Gouly , Marc Zyngier , Mark Rutland , Oliver Upton , Paolo Bonzini , Quentin Perret , Sean Christopherson , Steven Price , Thomas Huth , Will Deacon , Zenghui Yu , kvmarm@lists.cs.columbia.edu References: <20230127112248.136810-1-suzuki.poulose@arm.com> <20230303094618.GC361458@myrica> <1c91b777-982e-e71a-4829-51744e9555c5@arm.com> <20230303113905.GD361458@myrica> <20230303120800.ahtyc6et77ig4s27@orel> From: Suzuki K Poulose In-Reply-To: <20230303120800.ahtyc6et77ig4s27@orel> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/03/2023 12:08, Andrew Jones wrote: > On Fri, Mar 03, 2023 at 11:39:05AM +0000, Jean-Philippe Brucker wrote: >> On Fri, Mar 03, 2023 at 09:54:47AM +0000, Suzuki K Poulose wrote: >>> On 03/03/2023 09:46, Jean-Philippe Brucker wrote: >>>> On Thu, Mar 02, 2023 at 07:12:24AM +0900, Itaru Kitayama wrote: >>>>>>> I've tried your series in Real on CCA Host, but the KVM arch init >>>>>>> emits an Invalid argument error and terminates. >>>> >>>> This was the KVM_SET_ONE_REG for the SVE vector size. During my tests I >>>> didn't enable SVE in the host but shrinkwrap enables more options. >>> >>> Does the Qemu check for SVE capability on /dev/kvm ? For kvmtool, we >>> changed to using the VM instance and that would prevent using SVE, >>> until the RMM supports it. >> >> Yes, QEMU does check the SVE cap on /dev/kvm. I can propose changing it or >> complementing it with a VM check in my next version, it seems to work >> (though I need to double-check the VM fd lifetime). Same goes for >> KVM_CAP_STEAL_TIME, which I need to disable explicitly at the moment. > > I'm probably missing something since I haven't looked at this, but I'm > wondering what the "VM instance" check is and why it should be necessary. Userspace can check for a KVM_CAP_ on KVM fd (/dev/kvm) or a VM fd (returned via KVM_CREATE_VM). > Shouldn't KVM only expose capabilities which it can provide? I.e. the Correct, given now that we have different "types" of VMs possible on Arm64, (Normal vs Realm vs pVM), the capabilities of each of these could be different and thus we should use the KVM_CAP_ on the VM fd ( referred to VM instance above) and not the generic KVM fd. > "VM instance" check should be done by KVM and, when it fails, the SVE and > steal-time capabilities should return 0. > Correct. Suzuki > Thanks, > drew