From patchwork Fri Apr 4 10:29:15 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Bonzini X-Patchwork-Id: 14038290 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6BF831B6CEF for ; Fri, 4 Apr 2025 10:29:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743762571; cv=none; b=Hj2qXyQW/od13rMqRKyHShsp7Dzvvviuu/Bykqm7EDHptdZ3XbjCEgW8k7ERjF1G/I79/9Moh+mAukwL6DC5KP73nKcT9TvdKrr8XKoOtBsc1Ed/41617m9SfA60yO9uGTlhU8R/X37lw6R0DbdJTf7iXeaf71R3w/LtMWhZbE8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743762571; c=relaxed/simple; bh=wPnxq84hCxnZktHB5n2SHxZDe2iMMhApu5mhJ8fGjr0=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gvdTf9h01+t4yhIOztOH2q5DizLsBPC2oqgqwJB1DvJIClbcBA+yD6Z7PNkjbySS1tjYr55N1bc7CN6zldhJCHKTDXvfdVCAcaKFruZ8D+/F57M/pU9lDWEy3PVJ8X26Zsmjt4YzBYo2s5gitkLUvteW3gZ3M5+N4ywtTv9XlpY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=EGeP6yY9; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="EGeP6yY9" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1743762568; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wxOnUPdlMvuJ8v48pnMnggaUsB9ujf80p/0TOnoHhrk=; b=EGeP6yY9g19O+cGlZW/oHtFixl/XbdVG+4j+JlzD/WFj8UxghPbVuMmqIgJ4/pmhxz7sA5 ZBJ7EtLKaT5IalMPpAlF1LRRjMr6PebssTgx/Gnl/odhASm3b59bBwfPsyIdoMCbNgTBcT TauF6mgUbJcGU/x9CHHflN1qFPfRTSs= Received: from mail-ej1-f70.google.com (mail-ej1-f70.google.com [209.85.218.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-195-TZZ5NGhMPaW8TkxwqIOkTA-1; Fri, 04 Apr 2025 06:29:26 -0400 X-MC-Unique: TZZ5NGhMPaW8TkxwqIOkTA-1 X-Mimecast-MFC-AGG-ID: TZZ5NGhMPaW8TkxwqIOkTA_1743762566 Received: by mail-ej1-f70.google.com with SMTP id a640c23a62f3a-ac2aa3513ccso161410666b.0 for ; Fri, 04 Apr 2025 03:29:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743762565; x=1744367365; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=wxOnUPdlMvuJ8v48pnMnggaUsB9ujf80p/0TOnoHhrk=; b=aP2zBvzUdYphFuclN9M5wbOW6nMy/G0tIO4fHUwdCAfNcX1u90BMdO41BnHmNfGKxj FMDlnOcYaRDbHLa/7SUV/RLz1AkXHo17RLLGBVs11Eq7nuK3RvEzuxhk5JLAiRttrAlx jq3fupubuDVXAq6F+tn7JQ/iKBb2aVlt0+Dkk+EpWTHXhnf77C3oZXX868Hkxk23pYfj iIwIMh8M4vZO+XomE6INA9GU4iEizL/NYRpiQqUfQ3N+yecRolEhnajAMUswn90/5Pq7 uA7RD3jooJ8Oj8/mCzovPFoVewFzevsRFK4CdZM2JHRkHWeSvk3pnCHHw7RhmNTEeyi1 3Lsw== X-Forwarded-Encrypted: i=1; AJvYcCUJqNH1htyZsbnOuUaaFXg8dsP2PnFTnRHi44Kr3anrQk5/+anPHL5v2IJhIzMQEdzCjWI=@vger.kernel.org X-Gm-Message-State: AOJu0YxpAv4llgVhXRCaVoO1j748a731+IkeKAaFO5X9h2N/4QGIhxgp 86h+g13WYcdJs0lAFaVxf/ah0Hl5xJKpGbovzPwL4pmTiQ/bLR2FoIhlvYVyisR++bhKkgAg6Z9 aVMhhdgv/v8OpTOFzEZn3Lf5vhgMOwdw44qU1cpPB/Dw3SFUftaOmfN5l9Q== X-Gm-Gg: ASbGncsoJvcaIKlwlYWjsq5kQeckLGyMZ6c21tTwEwmpqbnIAj9NjfOOhz4UfXRfqpz 2bRq9p0CWtMt77HSOq3D30h8IfKkMIxJ2twd4YuZ0W/IEq+ZNTfilXHK9dkLKWTayDNXRovV9kL LmbAkWLdTLWebAhe9yXiqTpJYvZ3iDX6Gn5Apbh8ffp2vZ8s2v+CMwKGid2tKVz3SzED4+RNEEe XkCAM9vm9N2r/HfwOG1oqpZsoI/wxn6Jmfgr+GOxJdqvJ+V2wJFBqOGGKfBRGWXdXyn9EyCpp0W s8uuq0bm58qy5wnIWfW1 X-Received: by 2002:a17:907:9801:b0:ac6:e33a:6a0d with SMTP id a640c23a62f3a-ac7d199c8e5mr253554666b.55.1743762565182; Fri, 04 Apr 2025 03:29:25 -0700 (PDT) X-Google-Smtp-Source: AGHT+IH8o0pRabc4+gB4uulEDJjEE2gwOSpzOcpXqcH6CxNlDKuFME6qGnzVcNfndR6IyXcr7RMoSA== X-Received: by 2002:a17:907:9801:b0:ac6:e33a:6a0d with SMTP id a640c23a62f3a-ac7d199c8e5mr253553166b.55.1743762564788; Fri, 04 Apr 2025 03:29:24 -0700 (PDT) Received: from [192.168.122.1] ([151.49.230.224]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ac7bfe5d688sm228256566b.33.2025.04.04.03.29.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Apr 2025 03:29:23 -0700 (PDT) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: [PATCH 1/5] Documentation: kvm: give correct name for KVM_CAP_SPAPR_MULTITCE Date: Fri, 4 Apr 2025 12:29:15 +0200 Message-ID: <20250404102919.171952-2-pbonzini@redhat.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250404102919.171952-1-pbonzini@redhat.com> References: <20250404102919.171952-1-pbonzini@redhat.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 The capability is incorrectly called KVM_CAP_PPC_MULTITCE in the documentation. Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index ef894e11727c..49a604154564 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -8862,10 +8862,9 @@ clearing the PVCLOCK_TSC_STABLE_BIT flag in Xen pvclock sources. This will be done when the KVM_CAP_XEN_HVM ioctl sets the KVM_XEN_HVM_CONFIG_PVCLOCK_TSC_UNSTABLE flag. -8.31 KVM_CAP_PPC_MULTITCE -------------------------- +8.31 KVM_CAP_SPAPR_MULTITCE +--------------------------- -:Capability: KVM_CAP_PPC_MULTITCE :Architectures: ppc :Type: vm From patchwork Fri Apr 4 10:29:16 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Bonzini X-Patchwork-Id: 14038291 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E1F311D5CDD for ; Fri, 4 Apr 2025 10:29:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743762573; cv=none; b=Z6shsLp+JL1cxpH/EWA3NykqnFTyAwQXhQwruPsACLx6rx8KAmDw4jHnpFWrTRBUx9hvs4Q1GCqh+4KW69X14bhSiSHEF0W6K8qHCuJ/bBlEggH6C6W7frWfqDhHduxHUZMpASBAgzBXyqzCj6kxbcYrwar7POtsH9valyb1VyI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743762573; c=relaxed/simple; bh=pIzQK1XQVUOehm2a0IDXKr9Yx+FlZ4I6aBSO5ZnRFr4=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tmAG5OR1PwceJ/Odx+9FJYZ93EJLBja/2mh5gMPMSXuyPNdYuf2800aEfyDeTUOOxhZKI0TqJrIQ4ekh75Y8gtOFjlMTnIqRo0qRar3vwYHXRizzvWkf0aQPApThXkH8cXSBNsDHAHtJxDriovMZ0YfVRUnPZcC6lsDW3Fpjoaw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=VvpTsL7X; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="VvpTsL7X" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1743762571; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mhILDOeGcZxr2T6k437hnDwGzh6WW1hiZTYtqJGkNJ8=; b=VvpTsL7X6POBppb8dd3pnEdSuxZJ1A5Pe6swSCmG3aL+glpQPWJ1C6Y7/p/OKK176D5Tc6 T1M0+yELpwjZCiEo2q+ITECIATTy61Q94eRq0DYgEtALjwZaxulebT6+/ZTtY+RrGP6Y1Z TZ+eU5N3r6Dc+loR/vl53U3q+RbPZ3o= Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-410-A1RDUENJMESqUwWq2eJIPg-1; Fri, 04 Apr 2025 06:29:29 -0400 X-MC-Unique: A1RDUENJMESqUwWq2eJIPg-1 X-Mimecast-MFC-AGG-ID: A1RDUENJMESqUwWq2eJIPg_1743762568 Received: by mail-ed1-f69.google.com with SMTP id 4fb4d7f45d1cf-5e5c808e777so1769298a12.0 for ; Fri, 04 Apr 2025 03:29:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743762567; x=1744367367; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mhILDOeGcZxr2T6k437hnDwGzh6WW1hiZTYtqJGkNJ8=; b=HRt19rD42gJPUaDBNC17K30yn9J4B1qNvp8bV5ZE/xIVGgszOSBYLzHbPRoxIKuBAJ WQIy3IAfXmc10wN8pPqnySA10/iTHhgzlh6MUIxb9g3KPTOCcNgJFUtCxNp0VtfmNtJ7 0XSSqDyiEiX3VDc4voZzQnSN7y7Yr9fyXUirYgvvPJjzoeFY49RYVG7yo1wkn7chqYg3 lg2WialoSTqCCBXfV9XDggurX8wz5TpW0bilHDhDuDZuttdiO36GFAdprla1dtZSU5S0 zbM91JATI7ENtZML3D3PxpVL5pPsNFMhj+vWUarjmw4io9iDydH+lyYookOdl0TqZE16 rG9w== X-Forwarded-Encrypted: i=1; AJvYcCURkobeacF9nVt0g6ntNTmVoNIUsNClT18Re9BnGVEDbAQyRuxQfxImd389mk4ZPdPtzuQ=@vger.kernel.org X-Gm-Message-State: AOJu0YzUNsp7iipoKssNnAGAC2mEO2r669HB7igq8clS6vjs+Xce37OE Th9qBzgJSF/AdbHnp8C++skmv+UzMjED2IB3Lt8JKNkyWn/5V3VFPWd+96JjOApmEmHiMAONoJY U62xHwGW7yR9AFdb4C0P12+EHmNPkSCVIA9nTNGIpE1S0DQnZkoghNgc5Kw== X-Gm-Gg: ASbGncvPYGzWMEcCL0ROr5GfGoYDa/j+I9+yhkQqpCMWTbv8qybW3oikx4PfrvZ6fSR 5MCuu+FHYEM4p3z8aRaQ5bG1F4ZlfBghq0nxRXxfZkIM31LaugnJvdB9ZQ4+ajS5EX9lwxkIK5c zPGhFUJNDUk3SJat+Pl/Yh1/KDennMQD2ZVN2/B9Ywx6kigDah82mfkLk0+vgyARx4Yx4ZTRAx4 eapi93UVbZwr7jxhm/kFwzO+fWiwNrJ6qz45mqEhUGd3+l0yNwS4XyhWmGa9zE97G4maddgjqnU dySHT81rBZqzYDZveZrU X-Received: by 2002:a05:6402:3593:b0:5e4:c532:d69d with SMTP id 4fb4d7f45d1cf-5f0b309b682mr2148143a12.0.1743762567336; Fri, 04 Apr 2025 03:29:27 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEmoV1MYcdwLtpfSGoF+5ukGiKvJOsY+H/bN0znAVOJPtTTDi9a2JwSVODl/Bxo9X77PYGQTQ== X-Received: by 2002:a05:6402:3593:b0:5e4:c532:d69d with SMTP id 4fb4d7f45d1cf-5f0b309b682mr2148129a12.0.1743762566946; Fri, 04 Apr 2025 03:29:26 -0700 (PDT) Received: from [192.168.122.1] ([151.49.230.224]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5f087ed1c68sm2047151a12.17.2025.04.04.03.29.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Apr 2025 03:29:26 -0700 (PDT) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: [PATCH 2/5] Documentation: kvm: drop "Capability" heading from capabilities Date: Fri, 4 Apr 2025 12:29:16 +0200 Message-ID: <20250404102919.171952-3-pbonzini@redhat.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250404102919.171952-1-pbonzini@redhat.com> References: <20250404102919.171952-1-pbonzini@redhat.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 It is redundant, and sometimes wrong. Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 11 ----------- 1 file changed, 11 deletions(-) diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 49a604154564..efca6cc32dd5 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -7977,7 +7977,6 @@ See Documentation/arch/x86/sgx.rst for more details. 7.26 KVM_CAP_PPC_RPT_INVALIDATE ------------------------------- -:Capability: KVM_CAP_PPC_RPT_INVALIDATE :Architectures: ppc :Type: vm @@ -8052,7 +8051,6 @@ upgrading the VMM process without interrupting the guest. 7.30 KVM_CAP_PPC_AIL_MODE_3 ------------------------------- -:Capability: KVM_CAP_PPC_AIL_MODE_3 :Architectures: ppc :Type: vm @@ -8066,7 +8064,6 @@ handling interrupts and system calls. 7.31 KVM_CAP_DISABLE_QUIRKS2 ---------------------------- -:Capability: KVM_CAP_DISABLE_QUIRKS2 :Parameters: args[0] - set of KVM quirks to disable :Architectures: x86 :Type: vm @@ -8910,7 +8907,6 @@ leaf. 8.34 KVM_CAP_EXIT_HYPERCALL --------------------------- -:Capability: KVM_CAP_EXIT_HYPERCALL :Architectures: x86 :Type: vm @@ -8929,7 +8925,6 @@ ENOSYS for the others. 8.35 KVM_CAP_PMU_CAPABILITY --------------------------- -:Capability: KVM_CAP_PMU_CAPABILITY :Architectures: x86 :Type: vm :Parameters: arg[0] is bitmask of PMU virtualization capabilities. @@ -8951,7 +8946,6 @@ should adjust CPUID leaf 0xA to reflect that the PMU is disabled. 8.36 KVM_CAP_ARM_SYSTEM_SUSPEND ------------------------------- -:Capability: KVM_CAP_ARM_SYSTEM_SUSPEND :Architectures: arm64 :Type: vm @@ -8961,7 +8955,6 @@ type KVM_SYSTEM_EVENT_SUSPEND to process the guest suspend request. 8.37 KVM_CAP_S390_PROTECTED_DUMP -------------------------------- -:Capability: KVM_CAP_S390_PROTECTED_DUMP :Architectures: s390 :Type: vm @@ -8974,7 +8967,6 @@ available and supports the `KVM_PV_DUMP_CPU` subcommand. 8.38 KVM_CAP_VM_DISABLE_NX_HUGE_PAGES ------------------------------------- -:Capability: KVM_CAP_VM_DISABLE_NX_HUGE_PAGES :Architectures: x86 :Type: vm :Parameters: arg[0] must be 0. @@ -8991,7 +8983,6 @@ This capability may only be set before any vCPUs are created. 8.39 KVM_CAP_S390_CPU_TOPOLOGY ------------------------------ -:Capability: KVM_CAP_S390_CPU_TOPOLOGY :Architectures: s390 :Type: vm @@ -9016,7 +9007,6 @@ must point to a byte where the value will be stored or retrieved from. 8.40 KVM_CAP_ARM_EAGER_SPLIT_CHUNK_SIZE --------------------------------------- -:Capability: KVM_CAP_ARM_EAGER_SPLIT_CHUNK_SIZE :Architectures: arm64 :Type: vm :Parameters: arg[0] is the new split chunk size. @@ -9043,7 +9033,6 @@ block sizes is exposed in KVM_CAP_ARM_SUPPORTED_BLOCK_SIZES as a 8.41 KVM_CAP_VM_TYPES --------------------- -:Capability: KVM_CAP_MEMORY_ATTRIBUTES :Architectures: x86 :Type: system ioctl From patchwork Fri Apr 4 10:29:17 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Bonzini X-Patchwork-Id: 14038292 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2EC4D1D8DE0 for ; Fri, 4 Apr 2025 10:29:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743762574; cv=none; b=f3VXu+pvMEHDAyC3fH2oqEkv+kXgfEqA72EsKjmRvbMG27GxQpUUgbDXZOPFvc8HufyPgq0X8buII3vbIp3rnbelB+YSXQDHRUKnrTFr83rY56GXodU98RbnBt9lST13vqWQA6AwBvnXfF6hP5s9jPnP5p05mawynCg3UM3d2bw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743762574; c=relaxed/simple; bh=ZXP9PdtNz5G4gmYwe9qut0Sxd9Ty7phi4XqNd27CsSM=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TXv7WyneGIyNwAMIs6Y5M4x+W4npdgG63L5sx0xCRIXD1CFiy7pFWIITineZCX/Z4mNMC3WiyLQO8bQwCaVLVWD0xTotEKkbDVf4QlN2AlAQZjG5YzjD3tBxuZKNIs2tPD1AyQUloF5v2XWt0r4HbqcQmA21w9K518lWau0/1vU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=fC/G40EX; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="fC/G40EX" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1743762572; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Fh7eVIHVK7DZbml0KKr5DVpGA1dcsH/iEq7JogkgDmY=; b=fC/G40EXrH3amn5X0kRTDKnfgse98NnxzYRpAVu7V2yUa2v4MIBxzPVYno8WohkmAX7xoA yp97eUdDjDCCUJsAsA4nHAkH1mb7kqCMirkcdqxB+xoX+KPPxo+GSYmZOnhiI3R9clp8VK ZW6aHTr25NqfvCNygswfdEVNiF+76HI= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-466-XdKHzxY5P6-tVBRzbfOOxg-1; Fri, 04 Apr 2025 06:29:30 -0400 X-MC-Unique: XdKHzxY5P6-tVBRzbfOOxg-1 X-Mimecast-MFC-AGG-ID: XdKHzxY5P6-tVBRzbfOOxg_1743762570 Received: by mail-ed1-f72.google.com with SMTP id 4fb4d7f45d1cf-5e6c14c0a95so1616118a12.0 for ; Fri, 04 Apr 2025 03:29:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743762569; x=1744367369; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Fh7eVIHVK7DZbml0KKr5DVpGA1dcsH/iEq7JogkgDmY=; b=FnoDlN9UdCE04XEjMGcD+e/t9+WTTA2B7us9UmLdC82ToOYE+ETLoc5zfiY/UaMJeL L6CSRC+xL6zvQ1gvmoUkjmrx8Dm7DeU7/8Lla8lQbyhdv1SRUeTfBzTl5DEJah96bh7G 0CJSqnx1HCi56bVNYaiLJeYeYEALa8PJ9rqCaBBrUvJXas3ELGOvLrun7rlXV9Fjqz8Y 24DyIIR2bYv/t+CgWlCJ3FQnwmRPviaRVtz3G7rczRADQteuQx2v4KsGHiqQNKXtFCJ6 Lfiurzqt731VQXWYa+BJjTlUJcJNu4/FZWu6ccilXlUwxQWl4zJmSaLHe7GpiKmWfDaU GYaQ== X-Forwarded-Encrypted: i=1; AJvYcCWn7hsn6gkVhsShnq0wtUHc8fxuyfuapS8v2lkCSLVyIPhZY1QD3hwYT6dEb4I+QBrLjAE=@vger.kernel.org X-Gm-Message-State: AOJu0YxFc8dr8MAeZXamFPHIyuOdtTHa92OoK9S3sjNtcbXXEI/tDgc6 oe49cHHxaER2iQCOgGYvVHLYnExrnUcuK/RGACS72pj96OBoo4tYHFLlkj6UFL3HnUBkp3lozBt qy1b8sZTqmMnU9q+OKJ/dlXR2rkuZT0luTEh2oDUx0EwIObFkbWeStFK8oQ== X-Gm-Gg: ASbGncsvWfDHH4/6qA61/91Wo+ZP1TzIxTKIxEEkTLAAuoGWoOkrdMwX1fgdth6GE/Z zjEprJQEKQbJKZZJxLBPevWZiHvxpYUc1e7O4QFMhSBcsOkP5bAZ6zjSNEKWpKG0A1yDmbdPEfg TqrxA2JqhVUKizYQgSGreyEVGDElsZgTpSmNGWHnv172dusmzYT702HYM1eORpQBwIBKKvXokiz VOD8K2gn+EpiZmAIVhxExNVKYhPQSRS4tD8FVsn5mmVXFSKX4fONcd4Gba8VnTDR05v3mRbaF0W N2OanCuW+x+UDGq9Z7X/ X-Received: by 2002:a05:6402:51d2:b0:5e4:92ca:34d0 with SMTP id 4fb4d7f45d1cf-5f0b3bce08cmr1901631a12.20.1743762569370; Fri, 04 Apr 2025 03:29:29 -0700 (PDT) X-Google-Smtp-Source: AGHT+IF8YM5bc59qwjlQ36hgK1HFf0sMPpa9wPrpfputnw4Z5kCzZUI7+et+MKVBd0PZ6GNYMaCHiQ== X-Received: by 2002:a05:6402:51d2:b0:5e4:92ca:34d0 with SMTP id 4fb4d7f45d1cf-5f0b3bce08cmr1901617a12.20.1743762569036; Fri, 04 Apr 2025 03:29:29 -0700 (PDT) Received: from [192.168.122.1] ([151.49.230.224]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5f088084f17sm2174115a12.61.2025.04.04.03.29.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Apr 2025 03:29:28 -0700 (PDT) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: [PATCH 3/5] Documentation: kvm: fix some definition lists Date: Fri, 4 Apr 2025 12:29:17 +0200 Message-ID: <20250404102919.171952-4-pbonzini@redhat.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250404102919.171952-1-pbonzini@redhat.com> References: <20250404102919.171952-1-pbonzini@redhat.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Ensure that they have a ":" in front of the defined item. Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index efca6cc32dd5..e5e7fd42b47c 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -7938,10 +7938,10 @@ by POWER10 processor. 7.24 KVM_CAP_VM_COPY_ENC_CONTEXT_FROM ------------------------------------- -Architectures: x86 SEV enabled -Type: vm -Parameters: args[0] is the fd of the source vm -Returns: 0 on success; ENOTTY on error +:Architectures: x86 SEV enabled +:Type: vm +:Parameters: args[0] is the fd of the source vm +:Returns: 0 on success; ENOTTY on error This capability enables userspace to copy encryption context from the vm indicated by the fd to the vm this is called on. @@ -8662,7 +8662,7 @@ limit the attack surface on KVM's MSR emulation code. 8.28 KVM_CAP_ENFORCE_PV_FEATURE_CPUID ------------------------------------- -Architectures: x86 +:Architectures: x86 When enabled, KVM will disable paravirtual features provided to the guest according to the bits in the KVM_CPUID_FEATURES CPUID leaf @@ -8896,7 +8896,7 @@ available to the guest on migration. 8.33 KVM_CAP_HYPERV_ENFORCE_CPUID --------------------------------- -Architectures: x86 +:Architectures: x86 When enabled, KVM will disable emulated Hyper-V features provided to the guest according to the bits Hyper-V CPUID feature leaves. Otherwise, all From patchwork Fri Apr 4 10:29:18 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Bonzini X-Patchwork-Id: 14038294 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 98DD11DF721 for ; Fri, 4 Apr 2025 10:29:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743762579; cv=none; b=L+nv4BBVXZ5DaUQkPqSI6TUjZLeZiK33kShyV5jJ44RliXn1ZrF5COdNvSMc2aBZt+gJ7/m4rWzBwAFZDBmbSYtWAQCQqv0+V2Au7tBj9GtzI9YW2bQvgvYcK9iEAKupkrDbozz/mKMKJGzaWzzgAvs6J/GLlMPmVwCww7X0n94= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743762579; c=relaxed/simple; bh=CnGisSdUMgZmT1g+dRY1dxa5R+FZNycVlK/w/d90e7g=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=uUBoK3OA32sJsFpbIsdA3BW1YfK0yaoK1j5LveSSu9tMjXG3E2lQZVNJKCUjupXZK0WKwaINnkJS2qcpX1P9RWEsy3+3MqT/yWg5idyJiXLKyCuiJQHd5/vyZqK5yROXVRqovMbWbgawSQ5gkz1diGMgNn+nMVzEvHDCPB1q/88= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=aJcxDyBS; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="aJcxDyBS" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1743762575; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=j5MqRx8rKecmKEsI9m0q4clCM4JP8q1qj8d7wHp+XCA=; b=aJcxDyBSIUDpOaKVzDtd46Av61RSezBQpKwFjIcWtqdpbW3ZCL2DuWDw/Ctft90z4Px7hn RAO3vG2QFJ+gv/N+UJCip0rGPT06vSf24Beh9qG0sZGY2TIuI++hKh4ck5JYmTHnVeiepc gPxabANwJHOORQs5lWzryvOPxt15rMs= Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-492-FvhGBAyQO0CJwxGn-rQReQ-1; Fri, 04 Apr 2025 06:29:34 -0400 X-MC-Unique: FvhGBAyQO0CJwxGn-rQReQ-1 X-Mimecast-MFC-AGG-ID: FvhGBAyQO0CJwxGn-rQReQ_1743762573 Received: by mail-ej1-f71.google.com with SMTP id a640c23a62f3a-ac6ef2d1b7dso159894066b.0 for ; Fri, 04 Apr 2025 03:29:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743762572; x=1744367372; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=j5MqRx8rKecmKEsI9m0q4clCM4JP8q1qj8d7wHp+XCA=; b=DdCOPfYUiH7sriE3Acrg2ND2iw9pG+EwrlcbJ2DGVslqt+KNz2AwtjOpAdl1wuD4Ip mF4BjNeUgIPnkvJ71hsf+7daQccYLQrJeW6FjQFZeVJ3GVTcTI/EQO5ibP1vLGD1EZ0e nKjNzX7DyJnPeXjFE434pRL1dnJ3KfnA17d0oFlC+l2rDftsKWcZd7aF0nHHVfdVnMK0 LpWgLJtMI/joGwo63ildMZr/Ao4w/FbMRD0MgnskruG82kjmguwatXpS+OA9lhoUbos+ p2Q4kQgCH1j6yrOzeP31aZHR/Hw1TYNJmoA2V75Xl4s+DkhU+jIP7XjsQRVPFEFbRBV2 PDpA== X-Forwarded-Encrypted: i=1; AJvYcCXEeCjkjx11WDeZ/YNg44v2EaKHAhIC9/rKpm+bCLuQcWXV5lN4Kx4z3Xhyb6uwmUhY+Mo=@vger.kernel.org X-Gm-Message-State: AOJu0YxZc8/5mwkPmXqr5oxfqBktcZ+NKTgg3I8CQ3RvpjZeyuQQm2ml +2ook3UDgHd8CrQw4tt7JnCiw94oq9f0A5DhUGo9JWNFuSdUKbFfOpsvLzMb9RSPxnF16cwFLe6 nI19VHD4t1sLKmn/WlciQp6TDGywX8oIVWK1WXC0jwmq9VznPkNwL1gsCQw== X-Gm-Gg: ASbGncslaHdPBVl+L6D3Pbol44XrsKaovGGv3atg1GSRvix1IhMLYUnPB+ipxorjwWc Lw1aNqNV+vC6ClbgMYPwoGIoeO+iOsgA2csCSbb/iSSn3a1CEvf5sjXC143yjHM1Lax+NzHOLka dTF+n8zYk3WLkr+CAIFgjFIiLuheQqu8R/pC9EzNCxL4eZtTdtljYvSvmTT0A3evb3IYeDWlPiv nc7OllcM6kUtMKK/+aT92SZussxz7tILD/zi+fEg7sbshBRxPNgpGYGx1AjuCkIlJF7cNozUMje SdJ+M+mfdXPwp3HJzOfc X-Received: by 2002:a17:907:97cd:b0:ac3:8537:904e with SMTP id a640c23a62f3a-ac7d6f1b6a3mr158988466b.49.1743762571827; Fri, 04 Apr 2025 03:29:31 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFoWybIi6xBVg/aMencX10xR0oUAn/mlt2+KoUr5i2dDQh9XWIAXEK2jiDUiRR6Mz1lhLOy/Q== X-Received: by 2002:a17:907:97cd:b0:ac3:8537:904e with SMTP id a640c23a62f3a-ac7d6f1b6a3mr158985566b.49.1743762571089; Fri, 04 Apr 2025 03:29:31 -0700 (PDT) Received: from [192.168.122.1] ([151.49.230.224]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ac7c013ebe9sm233275866b.99.2025.04.04.03.29.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Apr 2025 03:29:30 -0700 (PDT) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: [PATCH 4/5] Documentation: kvm: organize capabilities in the right section Date: Fri, 4 Apr 2025 12:29:18 +0200 Message-ID: <20250404102919.171952-5-pbonzini@redhat.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250404102919.171952-1-pbonzini@redhat.com> References: <20250404102919.171952-1-pbonzini@redhat.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Categorize the capabilities correctly. Section 6 is for enabled vCPU capabilities; section 7 is for enabled VM capabilities; section 8 is for informational ones. Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 678 +++++++++++++++++---------------- 1 file changed, 340 insertions(+), 338 deletions(-) diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index e5e7fd42b47c..469b64d229a6 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -7458,6 +7458,75 @@ Unused bitfields in the bitarrays must be set to zero. This capability connects the vcpu to an in-kernel XIVE device. +6.76 KVM_CAP_HYPERV_SYNIC +------------------------- + +:Architectures: x86 +:Target: vcpu + +This capability, if KVM_CHECK_EXTENSION indicates that it is +available, means that the kernel has an implementation of the +Hyper-V Synthetic interrupt controller(SynIC). Hyper-V SynIC is +used to support Windows Hyper-V based guest paravirt drivers(VMBus). + +In order to use SynIC, it has to be activated by setting this +capability via KVM_ENABLE_CAP ioctl on the vcpu fd. Note that this +will disable the use of APIC hardware virtualization even if supported +by the CPU, as it's incompatible with SynIC auto-EOI behavior. + +6.77 KVM_CAP_HYPERV_SYNIC2 +-------------------------- + +:Architectures: x86 +:Target: vcpu + +This capability enables a newer version of Hyper-V Synthetic interrupt +controller (SynIC). The only difference with KVM_CAP_HYPERV_SYNIC is that KVM +doesn't clear SynIC message and event flags pages when they are enabled by +writing to the respective MSRs. + +6.78 KVM_CAP_HYPERV_DIRECT_TLBFLUSH +----------------------------------- + +:Architectures: x86 +:Target: vcpu + +This capability indicates that KVM running on top of Hyper-V hypervisor +enables Direct TLB flush for its guests meaning that TLB flush +hypercalls are handled by Level 0 hypervisor (Hyper-V) bypassing KVM. +Due to the different ABI for hypercall parameters between Hyper-V and +KVM, enabling this capability effectively disables all hypercall +handling by KVM (as some KVM hypercall may be mistakenly treated as TLB +flush hypercalls by Hyper-V) so userspace should disable KVM identification +in CPUID and only exposes Hyper-V identification. In this case, guest +thinks it's running on Hyper-V and only use Hyper-V hypercalls. + +6.79 KVM_CAP_HYPERV_ENFORCE_CPUID +--------------------------------- + +:Architectures: x86 +:Target: vcpu + +When enabled, KVM will disable emulated Hyper-V features provided to the +guest according to the bits Hyper-V CPUID feature leaves. Otherwise, all +currently implemented Hyper-V features are provided unconditionally when +Hyper-V identification is set in the HYPERV_CPUID_INTERFACE (0x40000001) +leaf. + +6.80 KVM_CAP_ENFORCE_PV_FEATURE_CPUID +------------------------------------- + +:Architectures: x86 +:Target: vcpu + +When enabled, KVM will disable paravirtual features provided to the +guest according to the bits in the KVM_CPUID_FEATURES CPUID leaf +(0x40000001). Otherwise, a guest may use the paravirtual features +regardless of what has actually been exposed through the CPUID leaf. + +.. _KVM_CAP_DIRTY_LOG_RING: + + .. _cap_enable_vm: 7. Capabilities that can be enabled on VMs @@ -7974,23 +8043,6 @@ default. See Documentation/arch/x86/sgx.rst for more details. -7.26 KVM_CAP_PPC_RPT_INVALIDATE -------------------------------- - -:Architectures: ppc -:Type: vm - -This capability indicates that the kernel is capable of handling -H_RPT_INVALIDATE hcall. - -In order to enable the use of H_RPT_INVALIDATE in the guest, -user space might have to advertise it for the guest. For example, -IBM pSeries (sPAPR) guest starts using it if "hcall-rpt-invalidate" is -present in the "ibm,hypertas-functions" device-tree property. - -This capability is enabled for hypervisors on platforms like POWER9 -that support radix MMU. - 7.27 KVM_CAP_EXIT_ON_EMULATION_FAILURE -------------------------------------- @@ -8048,19 +8100,6 @@ indicated by the fd to the VM this is called on. This is intended to support intra-host migration of VMs between userspace VMMs, upgrading the VMM process without interrupting the guest. -7.30 KVM_CAP_PPC_AIL_MODE_3 -------------------------------- - -:Architectures: ppc -:Type: vm - -This capability indicates that the kernel supports the mode 3 setting for the -"Address Translation Mode on Interrupt" aka "Alternate Interrupt Location" -resource that is controlled with the H_SET_MODE hypercall. - -This capability allows a guest kernel to use a better-performance mode for -handling interrupts and system calls. - 7.31 KVM_CAP_DISABLE_QUIRKS2 ---------------------------- @@ -8240,27 +8279,6 @@ This capability is aimed to mitigate the threat that malicious VMs can cause CPU stuck (due to event windows don't open up) and make the CPU unavailable to host or other VMs. -7.34 KVM_CAP_MEMORY_FAULT_INFO ------------------------------- - -:Architectures: x86 -:Returns: Informational only, -EINVAL on direct KVM_ENABLE_CAP. - -The presence of this capability indicates that KVM_RUN will fill -kvm_run.memory_fault if KVM cannot resolve a guest page fault VM-Exit, e.g. if -there is a valid memslot but no backing VMA for the corresponding host virtual -address. - -The information in kvm_run.memory_fault is valid if and only if KVM_RUN returns -an error with errno=EFAULT or errno=EHWPOISON *and* kvm_run.exit_reason is set -to KVM_EXIT_MEMORY_FAULT. - -Note: Userspaces which attempt to resolve memory faults so that they can retry -KVM_RUN are encouraged to guard against repeatedly receiving the same -error/annotated fault. - -See KVM_EXIT_MEMORY_FAULT for more information. - 7.35 KVM_CAP_X86_APIC_BUS_CYCLES_NS ----------------------------------- @@ -8278,19 +8296,220 @@ by KVM_CHECK_EXTENSION. Note: Userspace is responsible for correctly configuring CPUID 0x15, a.k.a. the core crystal clock frequency, if a non-zero CPUID 0x15 is exposed to the guest. -7.36 KVM_CAP_X86_GUEST_MODE ------------------------------- +7.36 KVM_CAP_DIRTY_LOG_RING/KVM_CAP_DIRTY_LOG_RING_ACQ_REL +---------------------------------------------------------- + +:Architectures: x86, arm64 +:Type: vm +:Parameters: args[0] - size of the dirty log ring + +KVM is capable of tracking dirty memory using ring buffers that are +mmapped into userspace; there is one dirty ring per vcpu. + +The dirty ring is available to userspace as an array of +``struct kvm_dirty_gfn``. Each dirty entry is defined as:: + + struct kvm_dirty_gfn { + __u32 flags; + __u32 slot; /* as_id | slot_id */ + __u64 offset; + }; + +The following values are defined for the flags field to define the +current state of the entry:: + + #define KVM_DIRTY_GFN_F_DIRTY BIT(0) + #define KVM_DIRTY_GFN_F_RESET BIT(1) + #define KVM_DIRTY_GFN_F_MASK 0x3 + +Userspace should call KVM_ENABLE_CAP ioctl right after KVM_CREATE_VM +ioctl to enable this capability for the new guest and set the size of +the rings. Enabling the capability is only allowed before creating any +vCPU, and the size of the ring must be a power of two. The larger the +ring buffer, the less likely the ring is full and the VM is forced to +exit to userspace. The optimal size depends on the workload, but it is +recommended that it be at least 64 KiB (4096 entries). + +Just like for dirty page bitmaps, the buffer tracks writes to +all user memory regions for which the KVM_MEM_LOG_DIRTY_PAGES flag was +set in KVM_SET_USER_MEMORY_REGION. Once a memory region is registered +with the flag set, userspace can start harvesting dirty pages from the +ring buffer. + +An entry in the ring buffer can be unused (flag bits ``00``), +dirty (flag bits ``01``) or harvested (flag bits ``1X``). The +state machine for the entry is as follows:: + + dirtied harvested reset + 00 -----------> 01 -------------> 1X -------+ + ^ | + | | + +------------------------------------------+ + +To harvest the dirty pages, userspace accesses the mmapped ring buffer +to read the dirty GFNs. If the flags has the DIRTY bit set (at this stage +the RESET bit must be cleared), then it means this GFN is a dirty GFN. +The userspace should harvest this GFN and mark the flags from state +``01b`` to ``1Xb`` (bit 0 will be ignored by KVM, but bit 1 must be set +to show that this GFN is harvested and waiting for a reset), and move +on to the next GFN. The userspace should continue to do this until the +flags of a GFN have the DIRTY bit cleared, meaning that it has harvested +all the dirty GFNs that were available. + +Note that on weakly ordered architectures, userspace accesses to the +ring buffer (and more specifically the 'flags' field) must be ordered, +using load-acquire/store-release accessors when available, or any +other memory barrier that will ensure this ordering. + +It's not necessary for userspace to harvest the all dirty GFNs at once. +However it must collect the dirty GFNs in sequence, i.e., the userspace +program cannot skip one dirty GFN to collect the one next to it. + +After processing one or more entries in the ring buffer, userspace +calls the VM ioctl KVM_RESET_DIRTY_RINGS to notify the kernel about +it, so that the kernel will reprotect those collected GFNs. +Therefore, the ioctl must be called *before* reading the content of +the dirty pages. + +The dirty ring can get full. When it happens, the KVM_RUN of the +vcpu will return with exit reason KVM_EXIT_DIRTY_LOG_FULL. + +The dirty ring interface has a major difference comparing to the +KVM_GET_DIRTY_LOG interface in that, when reading the dirty ring from +userspace, it's still possible that the kernel has not yet flushed the +processor's dirty page buffers into the kernel buffer (with dirty bitmaps, the +flushing is done by the KVM_GET_DIRTY_LOG ioctl). To achieve that, one +needs to kick the vcpu out of KVM_RUN using a signal. The resulting +vmexit ensures that all dirty GFNs are flushed to the dirty rings. + +NOTE: KVM_CAP_DIRTY_LOG_RING_ACQ_REL is the only capability that +should be exposed by weakly ordered architecture, in order to indicate +the additional memory ordering requirements imposed on userspace when +reading the state of an entry and mutating it from DIRTY to HARVESTED. +Architecture with TSO-like ordering (such as x86) are allowed to +expose both KVM_CAP_DIRTY_LOG_RING and KVM_CAP_DIRTY_LOG_RING_ACQ_REL +to userspace. + +After enabling the dirty rings, the userspace needs to detect the +capability of KVM_CAP_DIRTY_LOG_RING_WITH_BITMAP to see whether the +ring structures can be backed by per-slot bitmaps. With this capability +advertised, it means the architecture can dirty guest pages without +vcpu/ring context, so that some of the dirty information will still be +maintained in the bitmap structure. KVM_CAP_DIRTY_LOG_RING_WITH_BITMAP +can't be enabled if the capability of KVM_CAP_DIRTY_LOG_RING_ACQ_REL +hasn't been enabled, or any memslot has been existing. + +Note that the bitmap here is only a backup of the ring structure. The +use of the ring and bitmap combination is only beneficial if there is +only a very small amount of memory that is dirtied out of vcpu/ring +context. Otherwise, the stand-alone per-slot bitmap mechanism needs to +be considered. + +To collect dirty bits in the backup bitmap, userspace can use the same +KVM_GET_DIRTY_LOG ioctl. KVM_CLEAR_DIRTY_LOG isn't needed as long as all +the generation of the dirty bits is done in a single pass. Collecting +the dirty bitmap should be the very last thing that the VMM does before +considering the state as complete. VMM needs to ensure that the dirty +state is final and avoid missing dirty pages from another ioctl ordered +after the bitmap collection. + +NOTE: Multiple examples of using the backup bitmap: (1) save vgic/its +tables through command KVM_DEV_ARM_{VGIC_GRP_CTRL, ITS_SAVE_TABLES} on +KVM device "kvm-arm-vgic-its". (2) restore vgic/its tables through +command KVM_DEV_ARM_{VGIC_GRP_CTRL, ITS_RESTORE_TABLES} on KVM device +"kvm-arm-vgic-its". VGICv3 LPI pending status is restored. (3) save +vgic3 pending table through KVM_DEV_ARM_VGIC_{GRP_CTRL, SAVE_PENDING_TABLES} +command on KVM device "kvm-arm-vgic-v3". + +7.37 KVM_CAP_PMU_CAPABILITY +--------------------------- :Architectures: x86 -:Returns: Informational only, -EINVAL on direct KVM_ENABLE_CAP. +:Type: vm +:Parameters: arg[0] is bitmask of PMU virtualization capabilities. +:Returns: 0 on success, -EINVAL when arg[0] contains invalid bits -The presence of this capability indicates that KVM_RUN will update the -KVM_RUN_X86_GUEST_MODE bit in kvm_run.flags to indicate whether the -vCPU was executing nested guest code when it exited. +This capability alters PMU virtualization in KVM. -KVM exits with the register state of either the L1 or L2 guest -depending on which executed at the time of an exit. Userspace must -take care to differentiate between these cases. +Calling KVM_CHECK_EXTENSION for this capability returns a bitmask of +PMU virtualization capabilities that can be adjusted on a VM. + +The argument to KVM_ENABLE_CAP is also a bitmask and selects specific +PMU virtualization capabilities to be applied to the VM. This can +only be invoked on a VM prior to the creation of VCPUs. + +At this time, KVM_PMU_CAP_DISABLE is the only capability. Setting +this capability will disable PMU virtualization for that VM. Usermode +should adjust CPUID leaf 0xA to reflect that the PMU is disabled. + +7.38 KVM_CAP_VM_DISABLE_NX_HUGE_PAGES +------------------------------------- + +:Architectures: x86 +:Type: vm +:Parameters: arg[0] must be 0. +:Returns: 0 on success, -EPERM if the userspace process does not + have CAP_SYS_BOOT, -EINVAL if args[0] is not 0 or any vCPUs have been + created. + +This capability disables the NX huge pages mitigation for iTLB MULTIHIT. + +The capability has no effect if the nx_huge_pages module parameter is not set. + +This capability may only be set before any vCPUs are created. + +7.39 KVM_CAP_ARM_EAGER_SPLIT_CHUNK_SIZE +--------------------------------------- + +:Architectures: arm64 +:Type: vm +:Parameters: arg[0] is the new split chunk size. +:Returns: 0 on success, -EINVAL if any memslot was already created. + +This capability sets the chunk size used in Eager Page Splitting. + +Eager Page Splitting improves the performance of dirty-logging (used +in live migrations) when guest memory is backed by huge-pages. It +avoids splitting huge-pages (into PAGE_SIZE pages) on fault, by doing +it eagerly when enabling dirty logging (with the +KVM_MEM_LOG_DIRTY_PAGES flag for a memory region), or when using +KVM_CLEAR_DIRTY_LOG. + +The chunk size specifies how many pages to break at a time, using a +single allocation for each chunk. Bigger the chunk size, more pages +need to be allocated ahead of time. + +The chunk size needs to be a valid block size. The list of acceptable +block sizes is exposed in KVM_CAP_ARM_SUPPORTED_BLOCK_SIZES as a +64-bit bitmap (each bit describing a block size). The default value is +0, to disable the eager page splitting. + +7.40 KVM_CAP_EXIT_HYPERCALL +--------------------------- + +:Architectures: x86 +:Type: vm + +This capability, if enabled, will cause KVM to exit to userspace +with KVM_EXIT_HYPERCALL exit reason to process some hypercalls. + +Calling KVM_CHECK_EXTENSION for this capability will return a bitmask +of hypercalls that can be configured to exit to userspace. +Right now, the only such hypercall is KVM_HC_MAP_GPA_RANGE. + +The argument to KVM_ENABLE_CAP is also a bitmask, and must be a subset +of the result of KVM_CHECK_EXTENSION. KVM will forward to userspace +the hypercalls whose corresponding bit is in the argument, and return +ENOSYS for the others. + +7.41 KVM_CAP_ARM_SYSTEM_SUSPEND +------------------------------- + +:Architectures: arm64 +:Type: vm + +When enabled, KVM will exit to userspace with KVM_EXIT_SYSTEM_EVENT of +type KVM_SYSTEM_EVENT_SUSPEND to process the guest suspend request. 8. Other capabilities. ====================== @@ -8309,21 +8528,6 @@ H_RANDOM hypercall backed by a hardware random-number generator. If present, the kernel H_RANDOM handler can be enabled for guest use with the KVM_CAP_PPC_ENABLE_HCALL capability. -8.2 KVM_CAP_HYPERV_SYNIC ------------------------- - -:Architectures: x86 - -This capability, if KVM_CHECK_EXTENSION indicates that it is -available, means that the kernel has an implementation of the -Hyper-V Synthetic interrupt controller(SynIC). Hyper-V SynIC is -used to support Windows Hyper-V based guest paravirt drivers(VMBus). - -In order to use SynIC, it has to be activated by setting this -capability via KVM_ENABLE_CAP ioctl on the vcpu fd. Note that this -will disable the use of APIC hardware virtualization even if supported -by the CPU, as it's incompatible with SynIC auto-EOI behavior. - 8.3 KVM_CAP_PPC_MMU_RADIX ------------------------- @@ -8469,16 +8673,6 @@ virtual SMT modes that can be set using KVM_CAP_PPC_SMT. If bit N (counting from the right) is set, then a virtual SMT mode of 2^N is available. -8.11 KVM_CAP_HYPERV_SYNIC2 --------------------------- - -:Architectures: x86 - -This capability enables a newer version of Hyper-V Synthetic interrupt -controller (SynIC). The only difference with KVM_CAP_HYPERV_SYNIC is that KVM -doesn't clear SynIC message and event flags pages when they are enabled by -writing to the respective MSRs. - 8.12 KVM_CAP_HYPERV_VP_INDEX ---------------------------- @@ -8493,7 +8687,6 @@ capability is absent, userspace can still query this msr's value. ------------------------------- :Architectures: s390 -:Parameters: none This capability indicates if the flic device will be able to get/set the AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute and allows @@ -8567,21 +8760,6 @@ This capability indicates that KVM supports paravirtualized Hyper-V IPI send hypercalls: HvCallSendSyntheticClusterIpi, HvCallSendSyntheticClusterIpiEx. -8.21 KVM_CAP_HYPERV_DIRECT_TLBFLUSH ------------------------------------ - -:Architectures: x86 - -This capability indicates that KVM running on top of Hyper-V hypervisor -enables Direct TLB flush for its guests meaning that TLB flush -hypercalls are handled by Level 0 hypervisor (Hyper-V) bypassing KVM. -Due to the different ABI for hypercall parameters between Hyper-V and -KVM, enabling this capability effectively disables all hypercall -handling by KVM (as some KVM hypercall may be mistakenly treated as TLB -flush hypercalls by Hyper-V) so userspace should disable KVM identification -in CPUID and only exposes Hyper-V identification. In this case, guest -thinks it's running on Hyper-V and only use Hyper-V hypercalls. - 8.22 KVM_CAP_S390_VCPU_RESETS ----------------------------- @@ -8659,142 +8837,6 @@ In combination with KVM_CAP_X86_USER_SPACE_MSR, this allows user space to trap and emulate MSRs that are outside of the scope of KVM as well as limit the attack surface on KVM's MSR emulation code. -8.28 KVM_CAP_ENFORCE_PV_FEATURE_CPUID -------------------------------------- - -:Architectures: x86 - -When enabled, KVM will disable paravirtual features provided to the -guest according to the bits in the KVM_CPUID_FEATURES CPUID leaf -(0x40000001). Otherwise, a guest may use the paravirtual features -regardless of what has actually been exposed through the CPUID leaf. - -.. _KVM_CAP_DIRTY_LOG_RING: - -8.29 KVM_CAP_DIRTY_LOG_RING/KVM_CAP_DIRTY_LOG_RING_ACQ_REL ----------------------------------------------------------- - -:Architectures: x86, arm64 -:Parameters: args[0] - size of the dirty log ring - -KVM is capable of tracking dirty memory using ring buffers that are -mmapped into userspace; there is one dirty ring per vcpu. - -The dirty ring is available to userspace as an array of -``struct kvm_dirty_gfn``. Each dirty entry is defined as:: - - struct kvm_dirty_gfn { - __u32 flags; - __u32 slot; /* as_id | slot_id */ - __u64 offset; - }; - -The following values are defined for the flags field to define the -current state of the entry:: - - #define KVM_DIRTY_GFN_F_DIRTY BIT(0) - #define KVM_DIRTY_GFN_F_RESET BIT(1) - #define KVM_DIRTY_GFN_F_MASK 0x3 - -Userspace should call KVM_ENABLE_CAP ioctl right after KVM_CREATE_VM -ioctl to enable this capability for the new guest and set the size of -the rings. Enabling the capability is only allowed before creating any -vCPU, and the size of the ring must be a power of two. The larger the -ring buffer, the less likely the ring is full and the VM is forced to -exit to userspace. The optimal size depends on the workload, but it is -recommended that it be at least 64 KiB (4096 entries). - -Just like for dirty page bitmaps, the buffer tracks writes to -all user memory regions for which the KVM_MEM_LOG_DIRTY_PAGES flag was -set in KVM_SET_USER_MEMORY_REGION. Once a memory region is registered -with the flag set, userspace can start harvesting dirty pages from the -ring buffer. - -An entry in the ring buffer can be unused (flag bits ``00``), -dirty (flag bits ``01``) or harvested (flag bits ``1X``). The -state machine for the entry is as follows:: - - dirtied harvested reset - 00 -----------> 01 -------------> 1X -------+ - ^ | - | | - +------------------------------------------+ - -To harvest the dirty pages, userspace accesses the mmapped ring buffer -to read the dirty GFNs. If the flags has the DIRTY bit set (at this stage -the RESET bit must be cleared), then it means this GFN is a dirty GFN. -The userspace should harvest this GFN and mark the flags from state -``01b`` to ``1Xb`` (bit 0 will be ignored by KVM, but bit 1 must be set -to show that this GFN is harvested and waiting for a reset), and move -on to the next GFN. The userspace should continue to do this until the -flags of a GFN have the DIRTY bit cleared, meaning that it has harvested -all the dirty GFNs that were available. - -Note that on weakly ordered architectures, userspace accesses to the -ring buffer (and more specifically the 'flags' field) must be ordered, -using load-acquire/store-release accessors when available, or any -other memory barrier that will ensure this ordering. - -It's not necessary for userspace to harvest the all dirty GFNs at once. -However it must collect the dirty GFNs in sequence, i.e., the userspace -program cannot skip one dirty GFN to collect the one next to it. - -After processing one or more entries in the ring buffer, userspace -calls the VM ioctl KVM_RESET_DIRTY_RINGS to notify the kernel about -it, so that the kernel will reprotect those collected GFNs. -Therefore, the ioctl must be called *before* reading the content of -the dirty pages. - -The dirty ring can get full. When it happens, the KVM_RUN of the -vcpu will return with exit reason KVM_EXIT_DIRTY_LOG_FULL. - -The dirty ring interface has a major difference comparing to the -KVM_GET_DIRTY_LOG interface in that, when reading the dirty ring from -userspace, it's still possible that the kernel has not yet flushed the -processor's dirty page buffers into the kernel buffer (with dirty bitmaps, the -flushing is done by the KVM_GET_DIRTY_LOG ioctl). To achieve that, one -needs to kick the vcpu out of KVM_RUN using a signal. The resulting -vmexit ensures that all dirty GFNs are flushed to the dirty rings. - -NOTE: KVM_CAP_DIRTY_LOG_RING_ACQ_REL is the only capability that -should be exposed by weakly ordered architecture, in order to indicate -the additional memory ordering requirements imposed on userspace when -reading the state of an entry and mutating it from DIRTY to HARVESTED. -Architecture with TSO-like ordering (such as x86) are allowed to -expose both KVM_CAP_DIRTY_LOG_RING and KVM_CAP_DIRTY_LOG_RING_ACQ_REL -to userspace. - -After enabling the dirty rings, the userspace needs to detect the -capability of KVM_CAP_DIRTY_LOG_RING_WITH_BITMAP to see whether the -ring structures can be backed by per-slot bitmaps. With this capability -advertised, it means the architecture can dirty guest pages without -vcpu/ring context, so that some of the dirty information will still be -maintained in the bitmap structure. KVM_CAP_DIRTY_LOG_RING_WITH_BITMAP -can't be enabled if the capability of KVM_CAP_DIRTY_LOG_RING_ACQ_REL -hasn't been enabled, or any memslot has been existing. - -Note that the bitmap here is only a backup of the ring structure. The -use of the ring and bitmap combination is only beneficial if there is -only a very small amount of memory that is dirtied out of vcpu/ring -context. Otherwise, the stand-alone per-slot bitmap mechanism needs to -be considered. - -To collect dirty bits in the backup bitmap, userspace can use the same -KVM_GET_DIRTY_LOG ioctl. KVM_CLEAR_DIRTY_LOG isn't needed as long as all -the generation of the dirty bits is done in a single pass. Collecting -the dirty bitmap should be the very last thing that the VMM does before -considering the state as complete. VMM needs to ensure that the dirty -state is final and avoid missing dirty pages from another ioctl ordered -after the bitmap collection. - -NOTE: Multiple examples of using the backup bitmap: (1) save vgic/its -tables through command KVM_DEV_ARM_{VGIC_GRP_CTRL, ITS_SAVE_TABLES} on -KVM device "kvm-arm-vgic-its". (2) restore vgic/its tables through -command KVM_DEV_ARM_{VGIC_GRP_CTRL, ITS_RESTORE_TABLES} on KVM device -"kvm-arm-vgic-its". VGICv3 LPI pending status is restored. (3) save -vgic3 pending table through KVM_DEV_ARM_VGIC_{GRP_CTRL, SAVE_PENDING_TABLES} -command on KVM device "kvm-arm-vgic-v3". - 8.30 KVM_CAP_XEN_HVM -------------------- @@ -8893,65 +8935,6 @@ This capability indicates that the KVM virtual PTP service is supported in the host. A VMM can check whether the service is available to the guest on migration. -8.33 KVM_CAP_HYPERV_ENFORCE_CPUID ---------------------------------- - -:Architectures: x86 - -When enabled, KVM will disable emulated Hyper-V features provided to the -guest according to the bits Hyper-V CPUID feature leaves. Otherwise, all -currently implemented Hyper-V features are provided unconditionally when -Hyper-V identification is set in the HYPERV_CPUID_INTERFACE (0x40000001) -leaf. - -8.34 KVM_CAP_EXIT_HYPERCALL ---------------------------- - -:Architectures: x86 -:Type: vm - -This capability, if enabled, will cause KVM to exit to userspace -with KVM_EXIT_HYPERCALL exit reason to process some hypercalls. - -Calling KVM_CHECK_EXTENSION for this capability will return a bitmask -of hypercalls that can be configured to exit to userspace. -Right now, the only such hypercall is KVM_HC_MAP_GPA_RANGE. - -The argument to KVM_ENABLE_CAP is also a bitmask, and must be a subset -of the result of KVM_CHECK_EXTENSION. KVM will forward to userspace -the hypercalls whose corresponding bit is in the argument, and return -ENOSYS for the others. - -8.35 KVM_CAP_PMU_CAPABILITY ---------------------------- - -:Architectures: x86 -:Type: vm -:Parameters: arg[0] is bitmask of PMU virtualization capabilities. -:Returns: 0 on success, -EINVAL when arg[0] contains invalid bits - -This capability alters PMU virtualization in KVM. - -Calling KVM_CHECK_EXTENSION for this capability returns a bitmask of -PMU virtualization capabilities that can be adjusted on a VM. - -The argument to KVM_ENABLE_CAP is also a bitmask and selects specific -PMU virtualization capabilities to be applied to the VM. This can -only be invoked on a VM prior to the creation of VCPUs. - -At this time, KVM_PMU_CAP_DISABLE is the only capability. Setting -this capability will disable PMU virtualization for that VM. Usermode -should adjust CPUID leaf 0xA to reflect that the PMU is disabled. - -8.36 KVM_CAP_ARM_SYSTEM_SUSPEND -------------------------------- - -:Architectures: arm64 -:Type: vm - -When enabled, KVM will exit to userspace with KVM_EXIT_SYSTEM_EVENT of -type KVM_SYSTEM_EVENT_SUSPEND to process the guest suspend request. - 8.37 KVM_CAP_S390_PROTECTED_DUMP -------------------------------- @@ -8964,22 +8947,6 @@ PV guests. The `KVM_PV_DUMP` command is available for the dump related UV data. Also the vcpu ioctl `KVM_S390_PV_CPU_COMMAND` is available and supports the `KVM_PV_DUMP_CPU` subcommand. -8.38 KVM_CAP_VM_DISABLE_NX_HUGE_PAGES -------------------------------------- - -:Architectures: x86 -:Type: vm -:Parameters: arg[0] must be 0. -:Returns: 0 on success, -EPERM if the userspace process does not - have CAP_SYS_BOOT, -EINVAL if args[0] is not 0 or any vCPUs have been - created. - -This capability disables the NX huge pages mitigation for iTLB MULTIHIT. - -The capability has no effect if the nx_huge_pages module parameter is not set. - -This capability may only be set before any vCPUs are created. - 8.39 KVM_CAP_S390_CPU_TOPOLOGY ------------------------------ @@ -9004,32 +8971,6 @@ structure. When getting the Modified Change Topology Report value, the attr->addr must point to a byte where the value will be stored or retrieved from. -8.40 KVM_CAP_ARM_EAGER_SPLIT_CHUNK_SIZE ---------------------------------------- - -:Architectures: arm64 -:Type: vm -:Parameters: arg[0] is the new split chunk size. -:Returns: 0 on success, -EINVAL if any memslot was already created. - -This capability sets the chunk size used in Eager Page Splitting. - -Eager Page Splitting improves the performance of dirty-logging (used -in live migrations) when guest memory is backed by huge-pages. It -avoids splitting huge-pages (into PAGE_SIZE pages) on fault, by doing -it eagerly when enabling dirty logging (with the -KVM_MEM_LOG_DIRTY_PAGES flag for a memory region), or when using -KVM_CLEAR_DIRTY_LOG. - -The chunk size specifies how many pages to break at a time, using a -single allocation for each chunk. Bigger the chunk size, more pages -need to be allocated ahead of time. - -The chunk size needs to be a valid block size. The list of acceptable -block sizes is exposed in KVM_CAP_ARM_SUPPORTED_BLOCK_SIZES as a -64-bit bitmap (each bit describing a block size). The default value is -0, to disable the eager page splitting. - 8.41 KVM_CAP_VM_TYPES --------------------- @@ -9049,6 +8990,67 @@ Do not use KVM_X86_SW_PROTECTED_VM for "real" VMs, and especially not in production. The behavior and effective ABI for software-protected VMs is unstable. +8.42 KVM_CAP_PPC_RPT_INVALIDATE +------------------------------- + +:Architectures: ppc + +This capability indicates that the kernel is capable of handling +H_RPT_INVALIDATE hcall. + +In order to enable the use of H_RPT_INVALIDATE in the guest, +user space might have to advertise it for the guest. For example, +IBM pSeries (sPAPR) guest starts using it if "hcall-rpt-invalidate" is +present in the "ibm,hypertas-functions" device-tree property. + +This capability is enabled for hypervisors on platforms like POWER9 +that support radix MMU. + +8.43 KVM_CAP_PPC_AIL_MODE_3 +--------------------------- + +:Architectures: ppc + +This capability indicates that the kernel supports the mode 3 setting for the +"Address Translation Mode on Interrupt" aka "Alternate Interrupt Location" +resource that is controlled with the H_SET_MODE hypercall. + +This capability allows a guest kernel to use a better-performance mode for +handling interrupts and system calls. + +8.44 KVM_CAP_MEMORY_FAULT_INFO +------------------------------ + +:Architectures: x86 + +The presence of this capability indicates that KVM_RUN will fill +kvm_run.memory_fault if KVM cannot resolve a guest page fault VM-Exit, e.g. if +there is a valid memslot but no backing VMA for the corresponding host virtual +address. + +The information in kvm_run.memory_fault is valid if and only if KVM_RUN returns +an error with errno=EFAULT or errno=EHWPOISON *and* kvm_run.exit_reason is set +to KVM_EXIT_MEMORY_FAULT. + +Note: Userspaces which attempt to resolve memory faults so that they can retry +KVM_RUN are encouraged to guard against repeatedly receiving the same +error/annotated fault. + +See KVM_EXIT_MEMORY_FAULT for more information. + +8.45 KVM_CAP_X86_GUEST_MODE +--------------------------- + +:Architectures: x86 + +The presence of this capability indicates that KVM_RUN will update the +KVM_RUN_X86_GUEST_MODE bit in kvm_run.flags to indicate whether the +vCPU was executing nested guest code when it exited. + +KVM exits with the register state of either the L1 or L2 guest +depending on which executed at the time of an exit. Userspace must +take care to differentiate between these cases. + 9. Known KVM API problems ========================= From patchwork Fri Apr 4 10:29:19 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Bonzini X-Patchwork-Id: 14038293 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 83DD61DF994 for ; Fri, 4 Apr 2025 10:29:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743762579; cv=none; b=Bu0Ful979K1EfIrDWGjv5w/z8grr/H7D78coPHVkAHyxMEaEedInXdCQAjfoLe5NLzdWpkgSoOMzUgI5bwsm+99bHE015PVpK3i09SssDUb0imFwIrKgmQrBB9f5OUlwSHy6k7OPBgt5P45YOI0a7PGJejbxuKQcmaZiMncRj6E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743762579; c=relaxed/simple; bh=5+rhWJ9/AaOnxl4/edvsj3Mhq/NPswu21jjxt69P2kM=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pwiLWzpbae2X7nwxBQeTU3qZzlKhe5W0d/25EYLMbNlWCflmTqAUZDdiBnvE6GjOKF7lLSVbyOWE0H0fV7gq+MJq9DlWHVuieZvp2gDUVKTpQJ4HXCgR0rQsgeogAcAaTVFqYYwBfVYUlK5t+2VBqaBzce5RLqPSpeIX4I5BBa4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=IvY6SDnu; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="IvY6SDnu" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1743762576; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=iIj6VBKjZOnFTh+4vM6JPksjZGxz/JfbdG4ThPXJ5PM=; b=IvY6SDnuSFXt7su3mg3DKmyWLo6F7h3xR4gjtCFfevLyNgSAqUGtu9/5bKZPMcs3RG5gdF 9FLrpBzwxb62+EPQLzTSbJJJLOflaENBPoKePRR6i5Y4OkM2olQa7RlngX0QyB9QnBVPWP zs2BZr2HZtYn82PSy0Bp01b7oYHutBM= Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-544-5_7Vtur6OpWo78WGkjQEKw-1; Fri, 04 Apr 2025 06:29:35 -0400 X-MC-Unique: 5_7Vtur6OpWo78WGkjQEKw-1 X-Mimecast-MFC-AGG-ID: 5_7Vtur6OpWo78WGkjQEKw_1743762574 Received: by mail-ej1-f71.google.com with SMTP id a640c23a62f3a-ac737973c9bso151018466b.2 for ; Fri, 04 Apr 2025 03:29:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743762573; x=1744367373; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=iIj6VBKjZOnFTh+4vM6JPksjZGxz/JfbdG4ThPXJ5PM=; b=haR2V5ea37JOjRtmsVKnpdRwOw4G73IF++gp5RS3OZL3ZpgwD2WzRwYKHE3atwKQBL rstHegcAi4pULjch9hxTv9qDAYU7t3l1RHQ17stniAYuMp+yJUMXyFYf7WfaLZJzuT3x 1FWVW7fst6Dc+6m9B3ovv+bbAfzatRCbQ0txKyQacY7nj+f2E6aeN8oTdSXhHJUJHdT4 0+b0Mnmav5B8x40fG4Zcx2dRrhOA+EACgM4mxa6oQLGE8c8yPJ9tADvTqcLgBZ0tCqBh 95zGvWYGBJsHpI2Vs3d+j8IdGzgC9lSSfYrtoSA9U1iLmHr2FoqDPURPxybCNYPxWP7p pBMg== X-Forwarded-Encrypted: i=1; AJvYcCWWEXbciZ6ZS/qBWeFJOSlbW+OHmagU6MyylJ/TGOv/bVckNRrbinUJKc39o10FkIoa03Y=@vger.kernel.org X-Gm-Message-State: AOJu0YwRWxfHc1s7V0GrZbE8WeGjiOEp/lFrdbddE+2ZdyxlZemiHVm0 6pMe8Zdh7v7Oo3VWkIqcEZXac3Y2DF6lRxJ5BnAj6VmIM4lQx/knsgNRUyNOB2rmzEXtbrjDZde rhcgT4vD/gr0etLY5DutdSNemxW7xj/KXV3l4Ej3ZUM6tUaTQ5BNT6ArHnQ== X-Gm-Gg: ASbGncugMieAPgAT4lhhGwW4/qp50o5EyLKxQXztKv2cd72QhCxskaVafUKb03+xmHB d4EEfnFnWlyz/mhylEf3wyJhC/ylZf27OHl1ngKrQlVnPoPKmvrEZj6ByvRPhm4Y0Jp5+9XoZ2+ T914N4vsV2NVr+peYR6Jb5ov7l1kY5mbYKtNnVmM6PgKufGBlnLj7TDKfzi71/7TyZl89ZuTEoY u6KKlGCESPAnRx3ZjvRrmSUhH0xhQd/ueW52rCE18wDs/RjHrKICfT0cVdNjrNwqeauZc8k00Go C/WtMJ3WVGkb8sHt+Ij0 X-Received: by 2002:a17:907:980f:b0:ac7:391b:e685 with SMTP id a640c23a62f3a-ac7d19fe8b9mr265179566b.59.1743762573237; Fri, 04 Apr 2025 03:29:33 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGxQWmbdXNbO0s0OLq5wavir8e/NorfNubB6SFVZLkKltTIV61PUBG1neVaqpwJooF4AHCdPA== X-Received: by 2002:a17:907:980f:b0:ac7:391b:e685 with SMTP id a640c23a62f3a-ac7d19fe8b9mr265177866b.59.1743762572908; Fri, 04 Apr 2025 03:29:32 -0700 (PDT) Received: from [192.168.122.1] ([151.49.230.224]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ac7c0184d0dsm227635666b.130.2025.04.04.03.29.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Apr 2025 03:29:32 -0700 (PDT) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: [PATCH 5/5] Documentation: kvm: remove KVM_CAP_MIPS_TE Date: Fri, 4 Apr 2025 12:29:19 +0200 Message-ID: <20250404102919.171952-6-pbonzini@redhat.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250404102919.171952-1-pbonzini@redhat.com> References: <20250404102919.171952-1-pbonzini@redhat.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Trap and emulate virtualization is not available anymore for MIPS. Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 14 -------------- 1 file changed, 14 deletions(-) diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 469b64d229a6..2a63a244e87a 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -8578,20 +8578,6 @@ may be incompatible with the MIPS VZ ASE. virtualization, including standard guest virtual memory segments. == ========================================================================== -8.6 KVM_CAP_MIPS_TE -------------------- - -:Architectures: mips - -This capability, if KVM_CHECK_EXTENSION on the main kvm handle indicates that -it is available, means that the trap & emulate implementation is available to -run guest code in user mode, even if KVM_CAP_MIPS_VZ indicates that hardware -assisted virtualisation is also available. KVM_VM_MIPS_TE (0) must be passed -to KVM_CREATE_VM to create a VM which utilises it. - -If KVM_CHECK_EXTENSION on a kvm VM handle indicates that this capability is -available, it means that the VM is using trap & emulate. - 8.7 KVM_CAP_MIPS_64BIT ----------------------