Message ID | 20230126235451.469087-5-gshan@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp553205wrn; Thu, 26 Jan 2023 16:01:26 -0800 (PST) X-Google-Smtp-Source: AK7set9uqa3ORP7nid2FfMWJEUFiF5ojcgVYcJ2euCJa2Z6Z/U5JfMfSOB5ugmT4Ebah/1TsR4LE X-Received: by 2002:a17:906:a411:b0:878:72f7:bd87 with SMTP id l17-20020a170906a41100b0087872f7bd87mr3190074ejz.6.1674777686665; Thu, 26 Jan 2023 16:01:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674777686; cv=none; d=google.com; s=arc-20160816; b=nkerOGHbTp650CY5apHbDzMX9Z8O+qwbC7edmCQ1VbGLgjcAx5+VLWIjbfTVFQ5L+s dw3uf0O2sf0NxPA/krXcZb7wPfor5arGrrn6dtb7HgrPbNyQ5AMKSSUFQ4zg64/+KjKM JLGTqHlnzCZj6B5N/w0keJbCOLhG1TngFnEeg/EfcLnFvqU6h4rSnGouyrLH9VVSVkue ygAEy173xaEKH8wf+uesMfUj7unC/9Cn8ePUyjHpzgD1dShbq/J9DREy2ko+tIJmggvv rLr6wLK6isU/6MbHCBno7aPUdQwnuIU6dSR/adSyESkjLRfQ1Us5BJmn3F1xGQK9NyVx x0Pw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=898ohfdzehorjeXOEBd+HSoOXx0TlEdaod7Ot+z55Ec=; b=rCsyAsb4DC4jTxNuBBLrloos+4KCwCqxPIUlzy4zpU2E1h+Ggtj4YGUcHni2XIfcbO cgi2WhkVbxBI39qMRCYOIGAvbSMJQUdqaNg8ScDHlu2ncc/+iQOxBukE4vvz4x2Jf3th 2EO/8Xn4FfwLBw8dV7qUoPbnN0kPyG1z1HCGwvb8fRXjJrxNkLwqdbP3mq+SrRpvspqG 3GyGKgHsqA60okASNSZ5190YxtCjrZ+GXLAIu6HDQg9zEVpT3fFAI02RMHsYDZFWf57L kH8qulbwNtgatHx24CP0yQnsEIvUt1nYWvFct7DEJ0wpLqPCc3B/lnJkhPRktcQILfmy 24Dw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Kpzq1e7A; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a5-20020a509b45000000b0049e2ac8d02fsi4149654edj.569.2023.01.26.16.01.01; Thu, 26 Jan 2023 16:01:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Kpzq1e7A; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233030AbjAZX4h (ORCPT <rfc822;lekhanya01809@gmail.com> + 99 others); Thu, 26 Jan 2023 18:56:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33218 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230217AbjAZX4d (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 26 Jan 2023 18:56:33 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4D70044BCC for <linux-kernel@vger.kernel.org>; Thu, 26 Jan 2023 15:55:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1674777343; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=898ohfdzehorjeXOEBd+HSoOXx0TlEdaod7Ot+z55Ec=; b=Kpzq1e7AR87RRImg/ms868pwPT1j8ZrusOyL4h6v8P2HQwdSDBD6k4cw+y+KYsTTCbcpdq gJxQHvvSvRMgeTG/HRTKKfcP/ijgnsL7OLravGBjH1t2I2JeG+tvICsJVnFp4t4IRK0swb 0rzerYW+Xmcs6WAm6sVqOR80oj2y/kI= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-84-G0DpR1_uM622mmKCTiCNqA-1; Thu, 26 Jan 2023 18:55:38 -0500 X-MC-Unique: G0DpR1_uM622mmKCTiCNqA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 33154858F09; Thu, 26 Jan 2023 23:55:37 +0000 (UTC) Received: from gshan.redhat.com (vpn2-54-98.bne.redhat.com [10.64.54.98]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BCD692166B26; Thu, 26 Jan 2023 23:55:29 +0000 (UTC) From: Gavin Shan <gshan@redhat.com> To: kvmarm@lists.linux.dev Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, pbonzini@redhat.com, corbet@lwn.net, maz@kernel.org, james.morse@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, yuzhe@nfschina.com, isaku.yamahata@intel.com, seanjc@google.com, ricarkol@google.com, eric.auger@redhat.com, renzhengeek@gmail.com, reijiw@google.com, shan.gavin@gmail.com Subject: [PATCH v3 4/4] KVM: arm64: Allow no running vcpu on saving vgic3 pending table Date: Fri, 27 Jan 2023 07:54:51 +0800 Message-Id: <20230126235451.469087-5-gshan@redhat.com> In-Reply-To: <20230126235451.469087-1-gshan@redhat.com> References: <20230126235451.469087-1-gshan@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1756131687697826190?= X-GMAIL-MSGID: =?utf-8?q?1756131687697826190?= |
Series |
Improve dirty ring warning report
|
|
Commit Message
Gavin Shan
Jan. 26, 2023, 11:54 p.m. UTC
We don't have a running VCPU context to save vgic3 pending table due to KVM_DEV_ARM_VGIC_{GRP_CTRL, SAVE_PENDING_TABLES} command on KVM device "kvm-arm-vgic-v3". The unknown case is caught by kvm-unit-tests. # ./kvm-unit-tests/tests/its-pending-migration WARNING: CPU: 120 PID: 7973 at arch/arm64/kvm/../../../virt/kvm/kvm_main.c:3325 \ mark_page_dirty_in_slot+0x60/0xe0 : mark_page_dirty_in_slot+0x60/0xe0 __kvm_write_guest_page+0xcc/0x100 kvm_write_guest+0x7c/0xb0 vgic_v3_save_pending_tables+0x148/0x2a0 vgic_set_common_attr+0x158/0x240 vgic_v3_set_attr+0x4c/0x5c kvm_device_ioctl+0x100/0x160 __arm64_sys_ioctl+0xa8/0xf0 invoke_syscall.constprop.0+0x7c/0xd0 el0_svc_common.constprop.0+0x144/0x160 do_el0_svc+0x34/0x60 el0_svc+0x3c/0x1a0 el0t_64_sync_handler+0xb4/0x130 el0t_64_sync+0x178/0x17c Use vgic_write_guest_lock() to save vgic3 pending table. Reported-by: Zenghui Yu <yuzenghui@huawei.com> Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> --- Documentation/virt/kvm/api.rst | 4 +++- arch/arm64/kvm/vgic/vgic-v3.c | 2 +- 2 files changed, 4 insertions(+), 2 deletions(-)
Comments
On 2023/1/27 07:54, Gavin Shan wrote: > We don't have a running VCPU context to save vgic3 pending table due > to KVM_DEV_ARM_VGIC_{GRP_CTRL, SAVE_PENDING_TABLES} command on KVM > device "kvm-arm-vgic-v3". The unknown case is caught by kvm-unit-tests. > > # ./kvm-unit-tests/tests/its-pending-migration > WARNING: CPU: 120 PID: 7973 at arch/arm64/kvm/../../../virt/kvm/kvm_main.c:3325 \ > mark_page_dirty_in_slot+0x60/0xe0 > : > mark_page_dirty_in_slot+0x60/0xe0 > __kvm_write_guest_page+0xcc/0x100 > kvm_write_guest+0x7c/0xb0 > vgic_v3_save_pending_tables+0x148/0x2a0 > vgic_set_common_attr+0x158/0x240 > vgic_v3_set_attr+0x4c/0x5c > kvm_device_ioctl+0x100/0x160 > __arm64_sys_ioctl+0xa8/0xf0 > invoke_syscall.constprop.0+0x7c/0xd0 > el0_svc_common.constprop.0+0x144/0x160 > do_el0_svc+0x34/0x60 > el0_svc+0x3c/0x1a0 > el0t_64_sync_handler+0xb4/0x130 > el0t_64_sync+0x178/0x17c > > Use vgic_write_guest_lock() to save vgic3 pending table. > > Reported-by: Zenghui Yu <yuzenghui@huawei.com> > Signed-off-by: Gavin Shan <gshan@redhat.com> > Reviewed-by: Oliver Upton <oliver.upton@linux.dev> > --- > Documentation/virt/kvm/api.rst | 4 +++- > arch/arm64/kvm/vgic/vgic-v3.c | 2 +- > 2 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > index 40ada313faa3..07f07668995e 100644 > --- a/Documentation/virt/kvm/api.rst > +++ b/Documentation/virt/kvm/api.rst > @@ -8074,7 +8074,9 @@ 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". vgic3 LPI pending status is restored. > +"kvm-arm-vgic-its". vgic3 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". Can we summarize these 3 examples with something like: "when the guest memory (pending tables, ITS tables, etc) is dirtied by the virtual GIC or ITS, which is typically triggered by a userspace request (e.g., KVM_DEV_ARM_ITS_SAVE_TABLES) and doesn't require a running VCPU context"? In case there will be more no-running-vcpu kvm_write_guest_lock() cases in the VGIC emulation code in future and we have to extend the documentation.. But I don't have objection to your writing and the whole series looks good. Thanks, Zenghui
Hi Zenghui, On 1/28/23 2:57 AM, Zenghui Yu wrote: > On 2023/1/27 07:54, Gavin Shan wrote: >> We don't have a running VCPU context to save vgic3 pending table due >> to KVM_DEV_ARM_VGIC_{GRP_CTRL, SAVE_PENDING_TABLES} command on KVM >> device "kvm-arm-vgic-v3". The unknown case is caught by kvm-unit-tests. >> >> # ./kvm-unit-tests/tests/its-pending-migration >> WARNING: CPU: 120 PID: 7973 at arch/arm64/kvm/../../../virt/kvm/kvm_main.c:3325 \ >> mark_page_dirty_in_slot+0x60/0xe0 >> : >> mark_page_dirty_in_slot+0x60/0xe0 >> __kvm_write_guest_page+0xcc/0x100 >> kvm_write_guest+0x7c/0xb0 >> vgic_v3_save_pending_tables+0x148/0x2a0 >> vgic_set_common_attr+0x158/0x240 >> vgic_v3_set_attr+0x4c/0x5c >> kvm_device_ioctl+0x100/0x160 >> __arm64_sys_ioctl+0xa8/0xf0 >> invoke_syscall.constprop.0+0x7c/0xd0 >> el0_svc_common.constprop.0+0x144/0x160 >> do_el0_svc+0x34/0x60 >> el0_svc+0x3c/0x1a0 >> el0t_64_sync_handler+0xb4/0x130 >> el0t_64_sync+0x178/0x17c >> >> Use vgic_write_guest_lock() to save vgic3 pending table. >> >> Reported-by: Zenghui Yu <yuzenghui@huawei.com> >> Signed-off-by: Gavin Shan <gshan@redhat.com> >> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> >> --- >> Documentation/virt/kvm/api.rst | 4 +++- >> arch/arm64/kvm/vgic/vgic-v3.c | 2 +- >> 2 files changed, 4 insertions(+), 2 deletions(-) >> >> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst >> index 40ada313faa3..07f07668995e 100644 >> --- a/Documentation/virt/kvm/api.rst >> +++ b/Documentation/virt/kvm/api.rst >> @@ -8074,7 +8074,9 @@ 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". vgic3 LPI pending status is restored. >> +"kvm-arm-vgic-its". vgic3 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". > > Can we summarize these 3 examples with something like: "when the guest > memory (pending tables, ITS tables, etc) is dirtied by the virtual GIC > or ITS, which is typically triggered by a userspace request (e.g., > KVM_DEV_ARM_ITS_SAVE_TABLES) and doesn't require a running VCPU > context"? In case there will be more no-running-vcpu > kvm_write_guest_lock() cases in the VGIC emulation code in future and we > have to extend the documentation.. > > But I don't have objection to your writing and the whole series looks > good. > There are discussions about the documentation when dirty ring is enabled on ARM64. We prefer to keep the layout where the KVM devices and commands are explicitly documented. The application developer can identify them easily and to enable the backup bitmap when those KVM devices have been used. By the way, 'vgic3' will be replaced with 'VGICv3' as you suggested in another reply. Thanks, Gavin
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 40ada313faa3..07f07668995e 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -8074,7 +8074,9 @@ 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". vgic3 LPI pending status is restored. +"kvm-arm-vgic-its". vgic3 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 -------------------- diff --git a/arch/arm64/kvm/vgic/vgic-v3.c b/arch/arm64/kvm/vgic/vgic-v3.c index c94e4d7520fc..558ccc805fff 100644 --- a/arch/arm64/kvm/vgic/vgic-v3.c +++ b/arch/arm64/kvm/vgic/vgic-v3.c @@ -436,7 +436,7 @@ int vgic_v3_save_pending_tables(struct kvm *kvm) else val &= ~(1 << bit_nr); - ret = kvm_write_guest_lock(kvm, ptr, &val, 1); + ret = vgic_write_guest_lock(kvm, ptr, &val, 1); if (ret) goto out; }