From patchwork Sat Oct 22 15:48:15 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Emanuele Giuseppe Esposito X-Patchwork-Id: 536 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4242:0:0:0:0:0 with SMTP id s2csp1258422wrr; Sat, 22 Oct 2022 08:49:13 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7movciRDZI/0051bcjAopUAHMhFF8MK6oECHZKYONwAHZTKZIhYSBNdifHMqalzgfW3wcO X-Received: by 2002:aa7:d348:0:b0:45b:8ae3:ee3d with SMTP id m8-20020aa7d348000000b0045b8ae3ee3dmr22674729edr.428.1666453753287; Sat, 22 Oct 2022 08:49:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666453753; cv=none; d=google.com; s=arc-20160816; b=HNfjePwAjrnVZrMLXGa9K0S+DtMxswTENaAFC4arIQVSZNabB0PscTCRp5yg0+KV6T zoomSBxMrSo8gbuUCiYoLubk13K3W7hAX/AJIyR2t68ekOoNR48/MyxQ5ZciE1GUNS7n zcZWgP0hV08469gHXsLgAc1DJxEX2AJc1Fj9PU/H+Z6p64o4h1HwV+FFf52hpX4tHgp9 PEIbJAp5qvZdsAJYPipALXq3vf0QrMjzVNK1RKYiTzQjpf6E7b8Sf2B3yWuoGevbJlsW ieqW7EcdcVC52hiJax0CNiosoE0y9giZCy2n0tMU27G68egx4mY9wdTvZ3MNkkIVPcFI fs2Q== 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 :message-id:date:subject:cc:to:from:dkim-signature; bh=ubaULjUrByYJfUfr92/n81pA5XqiKjFVYnSXLbaGMQI=; b=kY3tPmJNdbB9eze8IHG7VuuP27A8LVWnKrWDCMmJZa/MomJs72vCLB6z0FuOziiiiv /Wl1LMyuwzGpccs7+AHipz49KhROTCAHoRId53LD6nxVJRcFIVsF3DZkM+9EcEXNf8vm N1uBrBQQ33y13m+Behvjx/NHlqRfwsEhmJd18j8iPT3EHoQ2wWStMixjwOYmgvxJMTti gNaZ+1fHphnoQPcC5S5tYLka5FP3rcRC0d72dnTHgoYqr1jl6siYKrVl4bpCuBNqRBJH H/yKn1fS6ZuD3RkbkQrPRCGcE2vEHO3+kQlDrHtD8z3dfGpNWxcG4vyP+ZW6pTFiT6Mh 1+aw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=WDr2tYd3; 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 xf13-20020a17090731cd00b00788361f96a2si25733129ejb.776.2022.10.22.08.48.48; Sat, 22 Oct 2022 08:49:13 -0700 (PDT) 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=WDr2tYd3; 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 S229846AbiJVPsb (ORCPT + 99 others); Sat, 22 Oct 2022 11:48:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34392 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229494AbiJVPs3 (ORCPT ); Sat, 22 Oct 2022 11:48:29 -0400 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 EFED424FED2 for ; Sat, 22 Oct 2022 08:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666453705; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=ubaULjUrByYJfUfr92/n81pA5XqiKjFVYnSXLbaGMQI=; b=WDr2tYd3p2cD3Klk+7vcl4XYlVrRMdZUfp3J2/LJDfgiFT6H2I0dK1khz6aXPQHEDOiwtD iCzdhnI79uVgqsJS237R9dP5M9B+9lZ75NF0+MFgfOdN228wjfs9PyEKqcQAo9LIGxKcAI dTViswD+/s7hMd5vvmoURyagLNA7Vn4= 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-140-N3ZNxMu6NdSkX-ZcmhlpQw-1; Sat, 22 Oct 2022 11:48:22 -0400 X-MC-Unique: N3ZNxMu6NdSkX-ZcmhlpQw-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id E44E2862FDF; Sat, 22 Oct 2022 15:48:21 +0000 (UTC) Received: from virtlab701.virt.lab.eng.bos.redhat.com (virtlab701.virt.lab.eng.bos.redhat.com [10.19.152.228]) by smtp.corp.redhat.com (Postfix) with ESMTP id 287BB49BB60; Sat, 22 Oct 2022 15:48:21 +0000 (UTC) From: Emanuele Giuseppe Esposito To: kvm@vger.kernel.org Cc: Paolo Bonzini , Jonathan Corbet , Maxim Levitsky , Sean Christopherson , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , David Hildenbrand , x86@kernel.org, "H. Peter Anvin" , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Emanuele Giuseppe Esposito Subject: [PATCH 0/4] KVM: API to block and resume all running vcpus in a vm Date: Sat, 22 Oct 2022 11:48:15 -0400 Message-Id: <20221022154819.1823133-1-eesposit@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 X-Spam-Status: No, score=-2.4 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: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747403410752016693?= X-GMAIL-MSGID: =?utf-8?q?1747403410752016693?= This new API allows the userspace to stop all running vcpus using KVM_KICK_ALL_RUNNING_VCPUS ioctl, and resume them with KVM_RESUME_ALL_KICKED_VCPUS. A "running" vcpu is a vcpu that is executing the KVM_RUN ioctl. This serie is especially helpful to userspace hypervisors like QEMU when they need to perform operations on memslots without the risk of having a vcpu reading them in the meanwhile. With "memslots operations" we mean grow, shrink, merge and split memslots, which are not "atomic" because there is a time window between the DELETE memslot operation and the CREATE one. Currently, each memslot operation is performed with one or more ioctls. For example, merging two memslots into one would imply: DELETE(m1) DELETE(m2) CREATE(m1+m2) And a vcpu could attempt to read m2 right after it is deleted, but before the new one is created. Therefore the simplest solution is to pause all vcpus in the kvm side, so that: - userspace just needs to call the new API before making memslots changes, keeping modifications to the minimum - dirty page updates are also performed when vcpus are blocked, so there is no time window between the dirty page ioctl and memslots modifications, since vcpus are all stopped. - no need to modify the existing memslots API Emanuele Giuseppe Esposito (4): linux-headers/linux/kvm.h: introduce kvm_userspace_memory_region_list ioctl KVM: introduce kvm_clear_all_cpus_request KVM: introduce memory transaction semaphore KVM: use signals to abort enter_guest/blocking and retry Documentation/virt/kvm/vcpu-requests.rst | 3 ++ arch/x86/include/asm/kvm_host.h | 2 ++ arch/x86/kvm/x86.c | 8 +++++ include/uapi/linux/kvm.h | 3 ++ virt/kvm/kvm_main.c | 45 ++++++++++++++++++++++++ 5 files changed, 61 insertions(+)