Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp4356246rwi; Sat, 22 Oct 2022 08:50:04 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7S/JLfSrmW2tE8MaVvHAEWQ6nd22GlzVoyAFcVwHoTfAuMumYJP9/eKOCqjRtx2mG1dfFI X-Received: by 2002:a05:6402:3588:b0:45d:7d14:baf2 with SMTP id y8-20020a056402358800b0045d7d14baf2mr22317499edc.1.1666453804496; Sat, 22 Oct 2022 08:50:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666453804; cv=none; d=google.com; s=arc-20160816; b=o0ZPEgVZghDRDj2WRWTXOpDidzVvDaTy3bo6Qcr8rnvHTxs6l9TdGiRHhEL9LW7qMt X1C8XjbXHnFkBNg+qfxUSJmPx3rL/pWkURcgCnnLo2Ec43MeIV9wLHFvjtp0EAv2bSl7 Iy1qm1NnxW4SdiM1v5+16gL2/pzKLBivbat1Q1ETDpnd4zoKYfntXNtbDcdN3G7MCUF5 b70ynF44y7QS+Pdx7J05WBQGagAfvzkXFezvfJTwqhrzG3xihpi3Kpm0lLxK2NkgTXzm pFVtPVKuC0EEe+SoPz1cl/U3K59OdLWYe2pOq+QRkNFjuvLXCP3WUlaLngGULdNbxKOX fekw== 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 Return-Path: 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.49.39; Sat, 22 Oct 2022 08:50:04 -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 Content-Transfer-Encoding: 8bit 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 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(+) -- 2.31.1