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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 496F5C433F5 for ; Wed, 24 Nov 2021 16:44:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242229AbhKXQsD (ORCPT ); Wed, 24 Nov 2021 11:48:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51992 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241782AbhKXQsC (ORCPT ); Wed, 24 Nov 2021 11:48:02 -0500 Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F1424C061574 for ; Wed, 24 Nov 2021 08:44:52 -0800 (PST) Received: by mail-pj1-x1029.google.com with SMTP id p18-20020a17090ad31200b001a78bb52876so5515548pju.3 for ; Wed, 24 Nov 2021 08:44:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G0XEOHQMGnJK/8jzhumR1dUDWBiMpAvYusRY69A+QEY=; b=eKZc15RFplIM1j+sc6nPMLo59g2hHqww5v6Ch0Ogt/sb5WaGNlNpE+Rs3fn936v5lE /Ud+RsF/XuWccx7dCQ7EyPY8kpZ0I+PN9phBLbgsB+gzia/f/pPM/RywK9SN/tXJLV7k 51opGqL28LBGKnfkdEZqfz/c2eL0n+kgusNELgPhpOP3iP+hQZsMPCDHBFm74MR09tPR oG/fh0qQPDlbArNQFYgO2gOihsBqB4aVTyzq6YML6Kyeof0O5GeGxKmvV8lj4RXmrHPq jMV/Xjlimauhw3+H/g6W8AKtqqbifVnmECZCqTNAENX5QWkUcJtpWeZAAtbIIkSDdu/u 2d5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G0XEOHQMGnJK/8jzhumR1dUDWBiMpAvYusRY69A+QEY=; b=qFpXFqcBEMR4MLV3bx9CBuQO6Mw6frRbPHyRnaV7N+5hhhJWkeaVpq1y+ON7A0ABlq 9E1VEAuxHXib+yCNDCyyuzhyKW0jZBiK6LSAGhtQ3mH/TrCUU/cyh9Z6inEsnZlUMpq3 3zj7wAFYUYInzJeYcL2/EFrHcRBVGPblCklbIRbQt2eAYSN68Y+ARYSm4QMYDQGxD+k6 TZrczgIMKaOgUPPEUqaatiVDsHvES8yu8bO17JM50O9E9Z27jbDynmCa+9jRozeqe1Q9 lKPPgnSwt0tXi0YLAs229djwfQknj6Vx8BlZRdBGa5O08zunprDj/j8vQhd4QlMwT00v IMaA== X-Gm-Message-State: AOAM532X2SFOzhJ4PsILh2p3WBmiAb6b3Up9F+UP3btiP91tOUgu+N+C udjvKyHp45T+wm2NiAKuMd1ah1L2gLgm3Rt1LNVFXQ== X-Google-Smtp-Source: ABdhPJykkFs1jEUeGODGlA7xKP0OubpatAx4WM/2/8+q/u0xJvkZku4bnMmyPdKIKUWU0zS3NOMpnWmjGnWJ2Zg38BA= X-Received: by 2002:a17:90b:380d:: with SMTP id mq13mr10825100pjb.110.1637772292285; Wed, 24 Nov 2021 08:44:52 -0800 (PST) MIME-Version: 1.0 References: <20211117064359.2362060-1-reijiw@google.com> In-Reply-To: From: Reiji Watanabe Date: Wed, 24 Nov 2021 08:44:36 -0800 Message-ID: Subject: Re: [RFC PATCH v3 00/29] KVM: arm64: Make CPU ID registers writable by userspace To: Alexandru Elisei Cc: Marc Zyngier , kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, James Morse , Suzuki K Poulose , Paolo Bonzini , Will Deacon , Andrew Jones , Peng Liang , Peter Shier , Ricardo Koller , Oliver Upton , Jing Zhang , Raghavendra Rao Anata Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org Hi Alex, > > > The API documentation for KVM_ARM_VCPU_INIT states: > > > > > > "Userspace can call this function multiple times for a given vcpu, > > > including after the vcpu has been run. This will reset the vcpu to its > > > initial state. All calls to this function after the initial call must use > > > the same target and same set of feature flags, otherwise EINVAL will be > > > returned." > > > > > > The consequences of that, according to my understanding: > > > > > > 1. Any changes to the VCPU features made by KVM are observable by > > > userspace. > > > > > > 2. The features in KVM weren't designed and implemented to be disabled > > > after being enabled. > > > > > > With that in mind, I have two questions: > > > > > > 1. What happens when userspace disables a feature via the ID registers > > > which is set in vcpu->arch.features? Does the feature bit get cleared from > > > vcpu->arch.features? Does it stay set? If it gets cleared, is it now > > > possible for userspace to call KVM_ARM_VCPU_INIT again with a different set > > > of VCPU features (it doesn't look possible to me after looking at the > > > code). If it stays set, what does it mean when userspace calls > > > KVM_ARM_VCPU_INIT with a different set of features enabled than what is > > > present in the ID registers? Should the ID registers be changed to match > > > the features that userspace set in the last KVM_ARM_VCPU_INIT call (it > > > looks to me that the ID registers are not changed)? > > > > KVM will not allow userspace to set the ID register value that conflicts > > with CPU features that are configured by the initial KVM_ARM_VCPU_INIT > > (or there are a few more APIs). > > KVM_SET_ONE_REG for such requests will fail. > > > > > > > 2. What happens to vcpu->arch.features when userspace enables a feature via > > > the ID registers which is not present in the bitmap? > > > > The answer for this question is basically the same as above. > > Userspace is not allowed to enable a feature via the ID registers > > which is not present in the bit map. > > > > The cover lever included a brief explanation of this, but I will > > try to improve the explanation:-) > > So the ID registers are used to set the version of a feature which is present in > the VCPU features bitmap, not to enable or a disable a VCPU feature. Thank you > for the explanation! Yes, that is correct for the CPU features that can be enabled by KVM_ARM_VCPU_INIT (or KVM_ENABLE_CAP). For the other CPU features that are indicated in ID registers on the host, userspace can disable (hide) the features (or lower the level of features) for the guest by updating its ID registers. Thanks, Reiji 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 mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id CA947C433F5 for ; Wed, 24 Nov 2021 16:44:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 2C1F44B1EF; Wed, 24 Nov 2021 11:44:57 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@google.com Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27svFrYYNdrz; Wed, 24 Nov 2021 11:44:55 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id BFED14B1A0; Wed, 24 Nov 2021 11:44:55 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id C02CF4B190 for ; Wed, 24 Nov 2021 11:44:54 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAcxJpldi7eS for ; Wed, 24 Nov 2021 11:44:53 -0500 (EST) Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 6D2014B175 for ; Wed, 24 Nov 2021 11:44:53 -0500 (EST) Received: by mail-pj1-f44.google.com with SMTP id v23so2995640pjr.5 for ; Wed, 24 Nov 2021 08:44:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G0XEOHQMGnJK/8jzhumR1dUDWBiMpAvYusRY69A+QEY=; b=eKZc15RFplIM1j+sc6nPMLo59g2hHqww5v6Ch0Ogt/sb5WaGNlNpE+Rs3fn936v5lE /Ud+RsF/XuWccx7dCQ7EyPY8kpZ0I+PN9phBLbgsB+gzia/f/pPM/RywK9SN/tXJLV7k 51opGqL28LBGKnfkdEZqfz/c2eL0n+kgusNELgPhpOP3iP+hQZsMPCDHBFm74MR09tPR oG/fh0qQPDlbArNQFYgO2gOihsBqB4aVTyzq6YML6Kyeof0O5GeGxKmvV8lj4RXmrHPq jMV/Xjlimauhw3+H/g6W8AKtqqbifVnmECZCqTNAENX5QWkUcJtpWeZAAtbIIkSDdu/u 2d5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G0XEOHQMGnJK/8jzhumR1dUDWBiMpAvYusRY69A+QEY=; b=XVgTFmbBcd626sqZyIq3Q2PGUQ9WBNyUsSdz+3meXNgnvQSs0MIjMrPrYKW5s/r3rm j9+oeIv11PkDvzbONwoPA3lew7eNCUjZ7WJM/rFxEsD2AlOqBXdSMGWPYZj6sdCObR+V ww7di+QFKYgH1eSZml87qh+HgNZUFCp07eK67tVraPcODnuojZZfmDtVqRHwAzQ8OVgB CWFwMGNSYhHgtu1M8UfaA9ilAoiCPx+mTwAylA0usToUkuW46zXAdzsA7eoty4fFnJ2b iYo1O2t2P/rD+Fos6+9Q4ZSsZgpFexKljZcm1emNlq9ktLB8yHH+Id2Jd6xKnyD63A2o Z0Xg== X-Gm-Message-State: AOAM532raVSp7Fxq6c7lKY/q0A13LYzq8oaJgciD+Ditsp1JIs8XIy8Z UqWSQVir/70/KaFHI38jayyPgEvjOPelAswAt+hUig== X-Google-Smtp-Source: ABdhPJykkFs1jEUeGODGlA7xKP0OubpatAx4WM/2/8+q/u0xJvkZku4bnMmyPdKIKUWU0zS3NOMpnWmjGnWJ2Zg38BA= X-Received: by 2002:a17:90b:380d:: with SMTP id mq13mr10825100pjb.110.1637772292285; Wed, 24 Nov 2021 08:44:52 -0800 (PST) MIME-Version: 1.0 References: <20211117064359.2362060-1-reijiw@google.com> In-Reply-To: From: Reiji Watanabe Date: Wed, 24 Nov 2021 08:44:36 -0800 Message-ID: Subject: Re: [RFC PATCH v3 00/29] KVM: arm64: Make CPU ID registers writable by userspace To: Alexandru Elisei Cc: kvm@vger.kernel.org, Marc Zyngier , Peter Shier , Paolo Bonzini , Will Deacon , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu Hi Alex, > > > The API documentation for KVM_ARM_VCPU_INIT states: > > > > > > "Userspace can call this function multiple times for a given vcpu, > > > including after the vcpu has been run. This will reset the vcpu to its > > > initial state. All calls to this function after the initial call must use > > > the same target and same set of feature flags, otherwise EINVAL will be > > > returned." > > > > > > The consequences of that, according to my understanding: > > > > > > 1. Any changes to the VCPU features made by KVM are observable by > > > userspace. > > > > > > 2. The features in KVM weren't designed and implemented to be disabled > > > after being enabled. > > > > > > With that in mind, I have two questions: > > > > > > 1. What happens when userspace disables a feature via the ID registers > > > which is set in vcpu->arch.features? Does the feature bit get cleared from > > > vcpu->arch.features? Does it stay set? If it gets cleared, is it now > > > possible for userspace to call KVM_ARM_VCPU_INIT again with a different set > > > of VCPU features (it doesn't look possible to me after looking at the > > > code). If it stays set, what does it mean when userspace calls > > > KVM_ARM_VCPU_INIT with a different set of features enabled than what is > > > present in the ID registers? Should the ID registers be changed to match > > > the features that userspace set in the last KVM_ARM_VCPU_INIT call (it > > > looks to me that the ID registers are not changed)? > > > > KVM will not allow userspace to set the ID register value that conflicts > > with CPU features that are configured by the initial KVM_ARM_VCPU_INIT > > (or there are a few more APIs). > > KVM_SET_ONE_REG for such requests will fail. > > > > > > > 2. What happens to vcpu->arch.features when userspace enables a feature via > > > the ID registers which is not present in the bitmap? > > > > The answer for this question is basically the same as above. > > Userspace is not allowed to enable a feature via the ID registers > > which is not present in the bit map. > > > > The cover lever included a brief explanation of this, but I will > > try to improve the explanation:-) > > So the ID registers are used to set the version of a feature which is present in > the VCPU features bitmap, not to enable or a disable a VCPU feature. Thank you > for the explanation! Yes, that is correct for the CPU features that can be enabled by KVM_ARM_VCPU_INIT (or KVM_ENABLE_CAP). For the other CPU features that are indicated in ID registers on the host, userspace can disable (hide) the features (or lower the level of features) for the guest by updating its ID registers. Thanks, Reiji _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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 90C0FC433F5 for ; Wed, 24 Nov 2021 16:46:22 +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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=svLlDTgDYgbq5k3hzbUHEwplbh08D71+E2vq9EfcPjs=; b=l2M17Vt++ZR0kW eHano/TaRwHLciC8FSOj9tYxfcXwuQ8c0ZX95UYAkgiLIfM9/MUyGy39FDglOyN4Q7NbW+LrQgy6P Z6k/bHAxvoBMU93JDul/F1ieuels9fZFEOgrIk/hlug8KIqwT5DHNFqxwHUqwH8rDMaIpkNudAxCu 02mpm8F2irsWuGFfNC2VLW/2kRmczcygQUED9EuV5/GmHkmLEYu5VOHoKd17BO9i/wBGDKYuR0NwB pX11B+9FoSyrhVTc/dKGP1bHcE8Gu17yXjtGnxUVyrcj2d+m+ThyPATMfCGsaL8OYivDxuJVwHLVm SMoAn/hlewLCB+qeTwIw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mpvOF-005IjQ-UL; Wed, 24 Nov 2021 16:45:00 +0000 Received: from mail-pj1-x102d.google.com ([2607:f8b0:4864:20::102d]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mpvOA-005IiM-HG for linux-arm-kernel@lists.infradead.org; Wed, 24 Nov 2021 16:44:55 +0000 Received: by mail-pj1-x102d.google.com with SMTP id gf14-20020a17090ac7ce00b001a7a2a0b5c3so5503654pjb.5 for ; Wed, 24 Nov 2021 08:44:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G0XEOHQMGnJK/8jzhumR1dUDWBiMpAvYusRY69A+QEY=; b=eKZc15RFplIM1j+sc6nPMLo59g2hHqww5v6Ch0Ogt/sb5WaGNlNpE+Rs3fn936v5lE /Ud+RsF/XuWccx7dCQ7EyPY8kpZ0I+PN9phBLbgsB+gzia/f/pPM/RywK9SN/tXJLV7k 51opGqL28LBGKnfkdEZqfz/c2eL0n+kgusNELgPhpOP3iP+hQZsMPCDHBFm74MR09tPR oG/fh0qQPDlbArNQFYgO2gOihsBqB4aVTyzq6YML6Kyeof0O5GeGxKmvV8lj4RXmrHPq jMV/Xjlimauhw3+H/g6W8AKtqqbifVnmECZCqTNAENX5QWkUcJtpWeZAAtbIIkSDdu/u 2d5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G0XEOHQMGnJK/8jzhumR1dUDWBiMpAvYusRY69A+QEY=; b=h9lFG/DEJzU+La0UFdnWWCOdnRGPffckF3k1zSHH3UjJY9QvqvtdWrK29mGCfwyX7G 5Ff6kT0MWUbS6tuZcdS9wWdfAz79dDMcJSaKec+bqv6hWHCnHP5pM0vyHN2N7S/FkB6X X+cZvPB04H6ada4VoVGUp2VaGwSEQ9St5Y1YBdzMye8/7VScYK6RKbL1QyzD/zYgSF7W 7kbmBVJ7evQdi2oS3eb6v6IypsJZxN5sEAILP6Kr+BWk6YEwwlQ2HQeumsM7zLwCpPOT WgK8yo2xz+ADRpvXTZMpMOC82iGpeAnrp2mGzkiXvbYhjJCYqJsQcUPp6t4DxlNRlxl+ LVmQ== X-Gm-Message-State: AOAM530n9XArjxsuzrwZl0WS1gMKFYbc6GGQmUuXeRPkIvZk4Kwg4ov2 glv60rjkimSFLsWn+7Gluedy4rcN7rQbVh1Z5u1zrw== X-Google-Smtp-Source: ABdhPJykkFs1jEUeGODGlA7xKP0OubpatAx4WM/2/8+q/u0xJvkZku4bnMmyPdKIKUWU0zS3NOMpnWmjGnWJ2Zg38BA= X-Received: by 2002:a17:90b:380d:: with SMTP id mq13mr10825100pjb.110.1637772292285; Wed, 24 Nov 2021 08:44:52 -0800 (PST) MIME-Version: 1.0 References: <20211117064359.2362060-1-reijiw@google.com> In-Reply-To: From: Reiji Watanabe Date: Wed, 24 Nov 2021 08:44:36 -0800 Message-ID: Subject: Re: [RFC PATCH v3 00/29] KVM: arm64: Make CPU ID registers writable by userspace To: Alexandru Elisei Cc: Marc Zyngier , kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, James Morse , Suzuki K Poulose , Paolo Bonzini , Will Deacon , Andrew Jones , Peng Liang , Peter Shier , Ricardo Koller , Oliver Upton , Jing Zhang , Raghavendra Rao Anata X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211124_084454_596508_EDD1FE0E X-CRM114-Status: GOOD ( 33.32 ) 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, > > > The API documentation for KVM_ARM_VCPU_INIT states: > > > > > > "Userspace can call this function multiple times for a given vcpu, > > > including after the vcpu has been run. This will reset the vcpu to its > > > initial state. All calls to this function after the initial call must use > > > the same target and same set of feature flags, otherwise EINVAL will be > > > returned." > > > > > > The consequences of that, according to my understanding: > > > > > > 1. Any changes to the VCPU features made by KVM are observable by > > > userspace. > > > > > > 2. The features in KVM weren't designed and implemented to be disabled > > > after being enabled. > > > > > > With that in mind, I have two questions: > > > > > > 1. What happens when userspace disables a feature via the ID registers > > > which is set in vcpu->arch.features? Does the feature bit get cleared from > > > vcpu->arch.features? Does it stay set? If it gets cleared, is it now > > > possible for userspace to call KVM_ARM_VCPU_INIT again with a different set > > > of VCPU features (it doesn't look possible to me after looking at the > > > code). If it stays set, what does it mean when userspace calls > > > KVM_ARM_VCPU_INIT with a different set of features enabled than what is > > > present in the ID registers? Should the ID registers be changed to match > > > the features that userspace set in the last KVM_ARM_VCPU_INIT call (it > > > looks to me that the ID registers are not changed)? > > > > KVM will not allow userspace to set the ID register value that conflicts > > with CPU features that are configured by the initial KVM_ARM_VCPU_INIT > > (or there are a few more APIs). > > KVM_SET_ONE_REG for such requests will fail. > > > > > > > 2. What happens to vcpu->arch.features when userspace enables a feature via > > > the ID registers which is not present in the bitmap? > > > > The answer for this question is basically the same as above. > > Userspace is not allowed to enable a feature via the ID registers > > which is not present in the bit map. > > > > The cover lever included a brief explanation of this, but I will > > try to improve the explanation:-) > > So the ID registers are used to set the version of a feature which is present in > the VCPU features bitmap, not to enable or a disable a VCPU feature. Thank you > for the explanation! Yes, that is correct for the CPU features that can be enabled by KVM_ARM_VCPU_INIT (or KVM_ENABLE_CAP). For the other CPU features that are indicated in ID registers on the host, userspace can disable (hide) the features (or lower the level of features) for the guest by updating its ID registers. Thanks, Reiji _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel