From nobody Sun Feb 8 11:21:35 2026 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 887A01BEF87 for ; Fri, 4 Apr 2025 10:29:29 +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=1743762571; cv=none; b=HwfyNLLAdJjOh1GIbPSL7oU9gNVlA7pYsVvWEroXKsESfqnWF/Kk2VIG04NBwWXP32Bu7gYkgj6F7WajSZWKCXhcFJZAzH2lg/KPe8uBkqTM4nEzKowgxlbbgARYuTszD80KOH/ktekngXl6MQ5guZwiI8mE41uLQnTowRNFu8s= 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.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="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-282-iBigO-E8OzqDZYk0sJVpNQ-1; Fri, 04 Apr 2025 06:29:27 -0400 X-MC-Unique: iBigO-E8OzqDZYk0sJVpNQ-1 X-Mimecast-MFC-AGG-ID: iBigO-E8OzqDZYk0sJVpNQ_1743762566 Received: by mail-ej1-f70.google.com with SMTP id a640c23a62f3a-ac297c7a0c2so153818666b.3 for ; Fri, 04 Apr 2025 03:29:27 -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=oBNUxc2ExoZXgvA6S7u4/ISPS//rKLuosQKW+mzNrtuWmbGZhRPxVKFQeK5RjHOWaQ 2LkBymHvuBww3AC2TDx3D4Bzx9wpAcDqe5y11ZsX6UpA5VIWKx/uVsG1O1RLtUEpQymc GB6QO1STcE/eLdfkI3q9STy17vXSisbzmywDJCMgOB3Rntj42ItRhXxXfWOFhKMB0Cd5 5TYj2H+P22LmA1udFm6KFUHFtB/P5YKvXLdz1fO436rgw+zUYrkTPFekPI/SoQa1KBhA 1t3teO9GB/HSf+D+sMwzICc379qcxEuuf+dO5EQvCMwqvFGMY+RWFDSygFCP12YsvDu0 oOow== X-Gm-Message-State: AOJu0Yz8A8DQpmMMyp3Mb1T20bdNdn1GEA08fisoSJkdu5gD1bwtDwkq 7hUB58NpxmJ+bQo7SurTw7DbPRH2u7381RgJ5DuRs6uG4nN4Y8mknxubHCWla6s3WIOmM+MzF7W ANHqop6WsnHOB/pBagkBQugFTdxbMpBWsBlc7Zuk/md2xCww7xx9vQCNaYNsPLbtrQWSrJlq4bI XWoDt73WGz4haqpLo1CWTmTaJOMGYfRBD3mEiIpGePb3Yqgw== X-Gm-Gg: ASbGncseAH1Dt4JZXZNrH7oCIcX3udinZRcr2ohRUrexp9671zrxvti0uapYc/++WSB dTM9jitw8R3t6yWWTM+B+tX7XmueD0fJH5mvctMKFq0CNDvOW44GIqj/i7As373GcRj+0HzbXNx BogmfomcloCqHdGKsSgu8M3cbP1x1dv2dyyDuT5W/hctH/U3319YRHAoMsWtsBQC+IVmExJXjjW xhjkgJNJI/7XhIUPyQ/0yb32FQ63E27RMAYKP8YQVGynHHQRKjh0IvzHvSVyeWmBr2oIB/Isu2I iZs3vddb2cwG3OTKw0A2 X-Received: by 2002:a17:907:9801:b0:ac6:e33a:6a0d with SMTP id a640c23a62f3a-ac7d199c8e5mr253555266b.55.1743762565276; 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: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The capability is incorrectly called KVM_CAP_PPC_MULTITCE in the documentat= ion. 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 pvcl= ock sources. This will be done when the KVM_CAP_XEN_HVM ioctl sets the KVM_XEN_HVM_CONFIG_PVCLOCK_TSC_UNSTABLE flag. =20 -8.31 KVM_CAP_PPC_MULTITCE -------------------------- +8.31 KVM_CAP_SPAPR_MULTITCE +--------------------------- =20 -:Capability: KVM_CAP_PPC_MULTITCE :Architectures: ppc :Type: vm =20 --=20 2.49.0 From nobody Sun Feb 8 11:21:35 2026 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 8C64F1CDFD5 for ; Fri, 4 Apr 2025 10:29:31 +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=1743762573; cv=none; b=bEzkQv9TdaYjSUwwJjGFVKefA9M4WtTpTtpZqHf2/qZaDZFaPQOvtztqRwbO87eqbZDBTl99QNr0BCRm4vujhXp86V1SWeIj7jowg7xACvdaDJJc6/nHZbjTq/FRFIGIru+AA0ZGDu85x8ra0TQVNU25jYB8h8GwUCdUUyvPB44= 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=M9uWLOe7; 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="M9uWLOe7" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1743762570; 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=M9uWLOe7e7VBbtOnUD0p2LgkyMuy57sV308mhb2h4irgiunNyZo2c7mQjXI6FbImh8fx0X c6zYnW6aorItavWRjK1GFOMTb0BbIeJTnXyRXpX1EcvX2Lw0QTpc9pof1MTb50nP7k7i3X CJlfELgXgcRVUvaLycr2e8phR98XPyY= Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-277-Q3rCyVHsN7KUCmAHM2zwpA-1; Fri, 04 Apr 2025 06:29:29 -0400 X-MC-Unique: Q3rCyVHsN7KUCmAHM2zwpA-1 X-Mimecast-MFC-AGG-ID: Q3rCyVHsN7KUCmAHM2zwpA_1743762568 Received: by mail-ed1-f70.google.com with SMTP id 4fb4d7f45d1cf-5e5d9682f53so1828996a12.2 for ; Fri, 04 Apr 2025 03:29:29 -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=JA0tq887EIhpH4P4jlPHoTNVDjrg1Q3NK1yFeDxVyWI55JbcbVK9dFf/e4CHJDnlFk Yr7NSye3HvG89y0Fpq+WePC/FA1gXn3bvXYdkQT8Jf7FKkRuHWSH6mTOJ5QGbomkEaua rffJhePXjBUdFAqyVM+wBn2QEIXtAU7Yxmu9iiVLjbnRKqDQrSG6yK57abuOp6Np4pVG poDLMGKkSJZWpIayUDuJP1nQ2W2jGFgNRiVeLloU0uPQxVnojSr42qQHYdtPWGemp1Mr mzWwfvedzg7O4oLarrocFEEIb6TZIwy8qOBr1dvhDYN1wBSS3rIS7P/p2YvpFSDhkI2S e/0Q== X-Gm-Message-State: AOJu0YzLUqyHjminvftEpM53EBAlWFxJyqsG8lTi2SUnOsnzqxkh4QLu E5K7abvJwWhsmcQj+34Be9HIFNGtaIUChipRvJDEmm/et3xfeFDjrlsl+jIr2I7uruc3Knp6EzF +h0ol6bN+gDHP5hXwrhPmy+RZ+iOzOrqUSzjqIWDmbZv+lxAVrXw+ibcEUC1H+RKIXz+FnfT0Zg xErOdk/k7RVShxNGTWrSjd6RjyWmJnn53TV5wI5ixg//tA3Q== X-Gm-Gg: ASbGncsUrY76jKroo+1W83g3sF4e7VkgbIw6S1lmdLpkoxlzTgmOHi1j+4WqMUF6A7d HVmDmDEXN2D7jUsbA05gDAU/5d5o6zaZvaCVdPhNmGzIVu7Jiyh6jH/qcxThBCAgqPAJoDYdP2f adLBQjdJh3OgaBiOs0PgXPiD1WFdYpwgZPwtCoBvhAmBC5cFuEZCO4JOSrTFwWz3ZBHSNweM4Fi WRTbO5kC9qj3n5CBPHKurSVys+uWkYxPlwvCLrtLrUI7rXaEScfywS4JTqVCL1PrOwgYnKZuIAf hKdU3Dh/gDyma6W5wVA5 X-Received: by 2002:a05:6402:3593:b0:5e4:c532:d69d with SMTP id 4fb4d7f45d1cf-5f0b309b682mr2148145a12.0.1743762567418; 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: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 ------------------------------- =20 -:Capability: KVM_CAP_PPC_RPT_INVALIDATE :Architectures: ppc :Type: vm =20 @@ -8052,7 +8051,6 @@ upgrading the VMM process without interrupting the gu= est. 7.30 KVM_CAP_PPC_AIL_MODE_3 ------------------------------- =20 -:Capability: KVM_CAP_PPC_AIL_MODE_3 :Architectures: ppc :Type: vm =20 @@ -8066,7 +8064,6 @@ handling interrupts and system calls. 7.31 KVM_CAP_DISABLE_QUIRKS2 ---------------------------- =20 -: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 --------------------------- =20 -:Capability: KVM_CAP_EXIT_HYPERCALL :Architectures: x86 :Type: vm =20 @@ -8929,7 +8925,6 @@ ENOSYS for the others. 8.35 KVM_CAP_PMU_CAPABILITY --------------------------- =20 -: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 ------------------------------- =20 -:Capability: KVM_CAP_ARM_SYSTEM_SUSPEND :Architectures: arm64 :Type: vm =20 @@ -8961,7 +8955,6 @@ type KVM_SYSTEM_EVENT_SUSPEND to process the guest su= spend request. 8.37 KVM_CAP_S390_PROTECTED_DUMP -------------------------------- =20 -:Capability: KVM_CAP_S390_PROTECTED_DUMP :Architectures: s390 :Type: vm =20 @@ -8974,7 +8967,6 @@ available and supports the `KVM_PV_DUMP_CPU` subcomma= nd. 8.38 KVM_CAP_VM_DISABLE_NX_HUGE_PAGES ------------------------------------- =20 -: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 ------------------------------ =20 -:Capability: KVM_CAP_S390_CPU_TOPOLOGY :Architectures: s390 :Type: vm =20 @@ -9016,7 +9007,6 @@ must point to a byte where the value will be stored o= r retrieved from. 8.40 KVM_CAP_ARM_EAGER_SPLIT_CHUNK_SIZE --------------------------------------- =20 -: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 --------------------- =20 -:Capability: KVM_CAP_MEMORY_ATTRIBUTES :Architectures: x86 :Type: system ioctl =20 --=20 2.49.0 From nobody Sun Feb 8 11:21:35 2026 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 813F21B21B4 for ; Fri, 4 Apr 2025 10:29:33 +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=1743762575; cv=none; b=SFSGh742Q+s9Q/yuUh4rUNUt2gHhQLhOGewdrp3BvKtuDSL+wvuXoJ/HVpSI2Z0j5T+4rJPSAFdOQyCJTPYgfU8xBgqnfi2B7ZToQJDcL+CafiE67HEdjJNJxvSN6Gjqywa3e/AcQaF2psrClXJ7YtPndi3NZ2Qu68VgOPPTIbA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743762575; c=relaxed/simple; bh=ZXP9PdtNz5G4gmYwe9qut0Sxd9Ty7phi4XqNd27CsSM=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QQJqTOf31J3S1rS9AT7N0YwLh86qLu6jm/u1Rt8d0Q7J/1rrcvT/7dZVrH2qnYfzUDF2vpVwyyYt0VKOKachwORty7+ckCQ4b6sFl4E2fcaBH28dutSiO7s3J0See8L0StXZ0NG1+PYjlwQlBaLqtJWGf+g0kJ5JO1fFkWIiEdQ= 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.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="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-67-8CWqUdUrPH2sbYNP0bVlUA-1; Fri, 04 Apr 2025 06:29:31 -0400 X-MC-Unique: 8CWqUdUrPH2sbYNP0bVlUA-1 X-Mimecast-MFC-AGG-ID: 8CWqUdUrPH2sbYNP0bVlUA_1743762570 Received: by mail-ed1-f72.google.com with SMTP id 4fb4d7f45d1cf-5e82390b87fso1693699a12.3 for ; Fri, 04 Apr 2025 03:29:31 -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=o/ph+ovAHZZ2hzS/hjYkcijEkJEQ71zotxI+un2EeZGLfinTzRt0JmoqDCOFHloMlE EW9J0w+qkr+kr1SzlhSjonUtd7lBn9WwH9oGifr5zSKLyVFYLcjvWUGMZcKlPUCu/kSv OlAIsNSrRhkYGX3sJLZpiqMWDszpG8nxXFWM3Pz6dibxS8fHMWiF2WuPwNWeWlkjQRvk ilLuojU4AP392YDZcDcB9bsZex+WVNqYAq/27XemkNxg9ZOp5nHdt2Mn4c2ea76lHn1f 7eRPwvB9kgcyzocu3UuHastzeE9adpuyzXsyL6wCmjm75B76nPx9uI+RXG+iWhcyexBU 8mSQ== X-Gm-Message-State: AOJu0YzWTx8TVR/Pp9eGJQhBBtk+uIIe+QeSU5vG0qF4QId31vGDpHL2 T8nUo7L7//Zd0tI+GaUBZ6n3EMbsXZPmW7hFsEd6KmK3ifqHpJDlcot6YqVpIalhu83r7vz2LNP 41xTaQ9PclEJMfqKyWbG2JYSDgyRi6vElaIjpoQ/EWM0LjTs+/QZpr/Mjt8KayOtfvosnP9v9Sa wI76V0x0qMosWY5uPnHNSHhv3rgMdQdxK87EgMyPfwX+WdZg== X-Gm-Gg: ASbGncucOiYQAoyx+BK1Q4EvaMRuvqPpIlePRr29V90NaH4qA7JKoXUJs3GkGfzuZoS xyl7PUMSp8y+ZXWgV4EV/4aEbjrnTddiQ3SHAqMr62KJ8ANhxxv0LyNChQD1BsgEdZAqySVTjLv C1+nlLOgyGNJ4p2yOidQNIk19Lk1Rc54l2qvGdian4Fkrd5AbFrfw7g3THZZOHyovbzAe0IFwlo yswMzUOchfFAOwzIUAJcQ/xzFfky6pQyiZrxmUw8nag7DRsDDl8ttHqwZBcnYIvLE48+4e65dDw ooN6ercsdXMUKBMdCHd4 X-Received: by 2002:a05:6402:51d2:b0:5e4:92ca:34d0 with SMTP id 4fb4d7f45d1cf-5f0b3bce08cmr1901634a12.20.1743762569410; 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: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 ------------------------------------- =20 -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 =20 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 ------------------------------------- =20 -Architectures: x86 +:Architectures: x86 =20 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 --------------------------------- =20 -Architectures: x86 +:Architectures: x86 =20 When enabled, KVM will disable emulated Hyper-V features provided to the guest according to the bits Hyper-V CPUID feature leaves. Otherwise, all --=20 2.49.0 From nobody Sun Feb 8 11:21:35 2026 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 C49E21DF969 for ; Fri, 4 Apr 2025 10:29:36 +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=1743762579; cv=none; b=g3d1WFBd3fZ+5oDO7Q8q+x2Tsh/65O1FKt0LTV/DvgYyAlJTMw9m7EjVQ/fuBQ9iynui8/ygdPTzVYm8SegxlmlpWEO6ivvDK1eqVu272HD9n18Pa2pV8ATpXWNd6tEyc+8bv1aVfSkGksb+KV3dYFFecEprvAi0YNoKMBFG9Is= 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.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="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-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-203-kPPyBls2PhauiKmAsJyfVw-1; Fri, 04 Apr 2025 06:29:34 -0400 X-MC-Unique: kPPyBls2PhauiKmAsJyfVw-1 X-Mimecast-MFC-AGG-ID: kPPyBls2PhauiKmAsJyfVw_1743762573 Received: by mail-ej1-f70.google.com with SMTP id a640c23a62f3a-ac27f00a8a5so143183466b.3 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=j5MqRx8rKecmKEsI9m0q4clCM4JP8q1qj8d7wHp+XCA=; b=w0RgxXmwieFvETX/vc1PdDg7N2brO78uKWAWsFiUVRn01uhm1b0E8x2XhUJLocFSce 8DQElMfVWrLSVEV/pIgdYVjjNJmxRIvVFv5A6G5dg4Xnbiai0oUSSSx/wpJdS+hlO+06 oALZroadPntVe2PgY/TYJqK++5MP9UQjmHEc3CPIY/FqVBz2d9D29nKoI4IaWtZJtdV7 RgUW8N+OGL2bC5VJV2Ey6Lg7vUMj3ko5Z6LLoDWa0yj8XS1TrrHZRqiJZ14o8pZmeSDM xX10O3XKFa9CkvbCgrt4JFmIrDb44qPOhc6NSwDsBGsb758eZmObBNOtq4ZCbEtUo2ET 8rMA== X-Gm-Message-State: AOJu0YyiVac5wyoklwcOUNvD2a3siGuWz0voUYp7Uo+IlXUmZK4LsMCR BTOA5WRffzUWXtkVXxIwkmAfBRKDPTfh6HXqscS/RMaEc6ujEUz6ePF5bjyiWy5t45vPqlxFMRu g0XH7h5a4KpsMBuL1IuRBm+xOtZ+V/YjKJGPlaAjxLlZq4rohwxRkYz4hI3l2SO0LGBvagiqM1f hdUyvityuZmipmvizVYciDPtaWaNUxC8lsPfCwxanMLz1GfA== X-Gm-Gg: ASbGncsbFuXoM7HRDC8Ms218Y3YHqK4xyyD4vZQmBE2FgBEmb+Ugw1/+z92+OENz3OR hvF9KC7qnlFLhx+ytpmPACbbhSu+5a7QosB2+ob08DCWLTiOB0zrMjFWfAGKYv4z4BN3T1/IwTO UzH9+4dj1is3FPJmxeC9i4Zqlwik1h33ckxJdiziXs8KO8T53j/WTUZkMvkjpA0MeaxV2QNmILL AjQb26WbbmVmlA81wjwYhuqrFjq6fZsew2pKRRlWz9yTXQSA01ZoJBQBhwMUNC8UgWSXa63v+yQ mmkJiQVHWMyl476gCYb3 X-Received: by 2002:a17:907:97cd:b0:ac3:8537:904e with SMTP id a640c23a62f3a-ac7d6f1b6a3mr158990866b.49.1743762572252; Fri, 04 Apr 2025 03:29:32 -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: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 zer= o. =20 This capability connects the vcpu to an in-kernel XIVE device. =20 +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: =20 7. Capabilities that can be enabled on VMs @@ -7974,23 +8043,6 @@ default. =20 See Documentation/arch/x86/sgx.rst for more details. =20 -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 -------------------------------------- =20 @@ -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. =20 -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 ---------------------------- =20 @@ -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. =20 -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 vir= tual -address. - -The information in kvm_run.memory_fault is valid if and only if KVM_RUN re= turns -an error with errno=3DEFAULT or errno=3DEHWPOISON *and* kvm_run.exit_reaso= n is set -to KVM_EXIT_MEMORY_FAULT. - -Note: Userspaces which attempt to resolve memory faults so that they can r= etry -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 ----------------------------------- =20 @@ -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 g= uest. =20 -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_TABLE= S} +command on KVM device "kvm-arm-vgic-v3". + +7.37 KVM_CAP_PMU_CAPABILITY +--------------------------- =20 :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 =20 -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. =20 -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. =20 8. Other capabilities. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D @@ -8309,21 +8528,6 @@ H_RANDOM hypercall backed by a hardware random-numbe= r generator. If present, the kernel H_RANDOM handler can be enabled for guest use with the KVM_CAP_PPC_ENABLE_HCALL capability. =20 -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 ------------------------- =20 @@ -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. =20 -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 ---------------------------- =20 @@ -8493,7 +8687,6 @@ capability is absent, userspace can still query this = msr's value. ------------------------------- =20 :Architectures: s390 -:Parameters: none =20 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 paravirt= ualized Hyper-V IPI send hypercalls: HvCallSendSyntheticClusterIpi, HvCallSendSyntheticClusterIpiEx. =20 -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 ----------------------------- =20 @@ -8659,142 +8837,6 @@ In combination with KVM_CAP_X86_USER_SPACE_MSR, thi= s 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. =20 -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_TABLE= S} -command on KVM device "kvm-arm-vgic-v3". - 8.30 KVM_CAP_XEN_HVM -------------------- =20 @@ -8893,65 +8935,6 @@ This capability indicates that the KVM virtual PTP s= ervice is supported in the host. A VMM can check whether the service is available to the guest on migration. =20 -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 -------------------------------- =20 @@ -8964,22 +8947,6 @@ PV guests. The `KVM_PV_DUMP` command is available fo= r the dump related UV data. Also the vcpu ioctl `KVM_S390_PV_CPU_COMMAND` is available and supports the `KVM_PV_DUMP_CPU` subcommand. =20 -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 ------------------------------ =20 @@ -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. =20 -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 --------------------- =20 @@ -9049,6 +8990,67 @@ Do not use KVM_X86_SW_PROTECTED_VM for "real" VMs, a= nd especially not in production. The behavior and effective ABI for software-protected VMs is unstable. =20 +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 vir= tual +address. + +The information in kvm_run.memory_fault is valid if and only if KVM_RUN re= turns +an error with errno=3DEFAULT or errno=3DEHWPOISON *and* kvm_run.exit_reaso= n is set +to KVM_EXIT_MEMORY_FAULT. + +Note: Userspaces which attempt to resolve memory faults so that they can r= etry +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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D =20 --=20 2.49.0 From nobody Sun Feb 8 11:21:35 2026 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 CEE651E0083 for ; Fri, 4 Apr 2025 10:29:37 +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=1743762579; cv=none; b=i9aoZZNq1jgb34VX1g4kTpfCoOhZ7O9bcRy/i962k2nW6whq91R/BCz2l0TnOzmqWuDzk4RVHgrNvB3FeRByg0cOecAm8PR+W6mjv5hI/A1degr373Mq8YTo1rzzcEk5k19mSnEyFhqP6JPZf0RzdsTt0lleglERoXm/er2BtAw= 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.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="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-381-hPLVj5Q8NoOKbd7dqGcdow-1; Fri, 04 Apr 2025 06:29:35 -0400 X-MC-Unique: hPLVj5Q8NoOKbd7dqGcdow-1 X-Mimecast-MFC-AGG-ID: hPLVj5Q8NoOKbd7dqGcdow_1743762574 Received: by mail-ej1-f71.google.com with SMTP id a640c23a62f3a-ac3e0c1336dso137687066b.3 for ; Fri, 04 Apr 2025 03:29:35 -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=ahqr+4RqanVDaRCWFbXVCB4F8DqRg4fRxnzxFFUPm8g/I7VN85lD68ITos0qKBw8gv dDPrNiRt9gFLUNivwcOwkOry8bpyIWjNBhG/6t+yyvli46QvIQ57pJx965J0TtVWgNyk rcsLYQTSQnDap9wFJ7CX5LWTROFBUzm4mXXa0HePBH0Swh4wa3bO0CpTCwC+VuirWc2e EbDAWtYb9GR76F2e1DB4VCtkVAUqVSjsbSzMqNqWPCv5U+i27XOxiWrLq4M9E893sjfG C97sHf8QRsvt6eVlO8WZi3b5W3vGueSLmaZGPe0ubFwk1xM3C61dycgK9vmMwu9dPJY9 kO3Q== X-Gm-Message-State: AOJu0YwHZUgeNPwXaxq7p9kU5wvrqgucy1MyiOnejLbJb/4dfGB7wbaZ StpNRH4EU6yFCqb5w5t5EqOgRWZajEzSOuXr0T2v6sMWnocnkFDR8P425jRJAKIFg9UM5Q3tl9Y 7B8EPk05056kn6qzaQh2cPaTELrqAm5V7j6BRzDLLAzIWxZthnloW/w21kr0gDzw01h/0XiBYRl u/kjIXSiInLBZ/22a5pcmMQ56hcRI0BGEfSr4lsB1yvQIigg== X-Gm-Gg: ASbGnctW16+3SLcjsb+kuJL0jIyJnhhu15qMZjpaqGQ/Voh0fjG8ujiu6Nfnyjdo8JO JfxkfWJiyOOjhve4Qvg8I5+UR4Gh1vSs3Rx1Sn8pB+ej3E+WOJEe40fImVW2P+3JfJyNSrvYOwM 5w4iSRQvDLYnhPol9gKUqqf69OeQJ3LFOu83tuy9a/qFgUziJHSm1MHy4F+tRIeQjKIAAzSFr6u PsJJotrelTqbJy5ergqlSzSp9YZFvdD60UaPxccYlrai+PZhFlK7qA0Fw0W7OnniHd5JN/ftI2h deSNjaxOWsifhM6RzjCv X-Received: by 2002:a17:907:980f:b0:ac7:391b:e685 with SMTP id a640c23a62f3a-ac7d19fe8b9mr265179666b.59.1743762573273; 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: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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. =3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D =20 -8.6 KVM_CAP_MIPS_TE -------------------- - -:Architectures: mips - -This capability, if KVM_CHECK_EXTENSION on the main kvm handle indicates t= hat -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 hardwa= re -assisted virtualisation is also available. KVM_VM_MIPS_TE (0) must be pass= ed -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 ---------------------- =20 --=20 2.49.0