Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp615465rwb; Tue, 27 Sep 2022 02:08:59 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5bnATpIqtUqEoAX4QMuoPMzm4dec74V6LBQ3MY/6RQcOABF3oxDHqRl2Q822NV1yqcqqeq X-Received: by 2002:a17:907:72c5:b0:783:c3ac:ecbc with SMTP id du5-20020a17090772c500b00783c3acecbcmr5228798ejc.498.1664269739582; Tue, 27 Sep 2022 02:08:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1664269739; cv=none; d=google.com; s=arc-20160816; b=fma8VTuomCSJLb+8xVff7B4CCeDbYfIyVjyT4jHMGZlaRGVgWAIaeUq6iC/UWl9t4v /1kD10GT6a4203RHCmodc+QrP6jIVBcG0iXLZXS0ftbjfi0F8PXIqzlKqnB80lT4shv2 QcKdleCPyJnGYYq7VTWqqlnBWn0kaZESh2eBmy9/0cD8vUTQSzTub5nLKkksQHAhU49v wvq/fcuCRstdzjR0Jv1EMDWSqBZoHlFOVY5aF57Maq1oOhopjyQq6vFmsiH4m1Y6BrZS YYjzieCe7nDkTLBYfD6uMgNxdcInfV/C0YN+xL7j+v7aeyq/cLl6kKsrjmK0akmBwWMY LEDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=AM7Ag3R1FhhmxAI1wRPUG0RaWTwM4UqjFY6j2yTgwJQ=; b=Td8m25ZS/f9XFGRg+aJtDmtutJksvzGlZ+w8BNxX1flALAruPpBX/6P2Wh0s5Wj1jy YIZcXo7sbalJ1RyOV0G27jwH4XUYjVyoH86Qf9NwqFDM/L6EKxqvlw3haU6YoLiL9HHL /E5VtvOwjnBQvxfcReP9OKi0AYUchOko/qipegeNqEB3TTAwnvJyW5Z9LitQv8U33VzJ 76wG3VKEPKz4+gm5DNEOvd5HVi52+85kjIPqs5Yv2Q8lT1I/Oqc+n9fdHZJ3TDakUmhS ipZG8+TMq3f75CYA84pDuHoQtj7v5W2pb0FqApM7zF7zgMwQSplMyHCVLxkRlnrom3fZ VlMQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=JrUHYIPV; 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 i1-20020a05640242c100b0044eae9b2c48si1334275edc.273.2022.09.27.02.08.33; Tue, 27 Sep 2022 02:08:59 -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=JrUHYIPV; 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 S231365AbiI0IhG (ORCPT + 99 others); Tue, 27 Sep 2022 04:37:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45496 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230374AbiI0IgL (ORCPT ); Tue, 27 Sep 2022 04:36:11 -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 4BEAD2125C for ; Tue, 27 Sep 2022 01:35:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1664267749; 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=AM7Ag3R1FhhmxAI1wRPUG0RaWTwM4UqjFY6j2yTgwJQ=; b=JrUHYIPVk2MIpY8G3ZUnl5lMwHZmjtj1/79OJp2kLUnSh30ViSiDn807YlQ6FJELQY7Zwv HA7PrgLnxaUEnfi4vbfQbykjdqQJ3TLNWT6YiLT8z6BcKaviuIsOfioI9WA7qkULL7K1Pc t2Z3J4ViKEzgHMS/85JvOdArU3lF4as= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-226-QZHpahRqPdeFiVvdonorsA-1; Tue, 27 Sep 2022 04:35:48 -0400 X-MC-Unique: QZHpahRqPdeFiVvdonorsA-1 Received: by mail-qv1-f72.google.com with SMTP id m7-20020a0ce6e7000000b004ad69308f01so5336313qvn.9 for ; Tue, 27 Sep 2022 01:35:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date; bh=AM7Ag3R1FhhmxAI1wRPUG0RaWTwM4UqjFY6j2yTgwJQ=; b=hanqlulHEaQSGVdAy6dRvomjC0/jLHahhqzvY3m8RcM5zPWta3krPdHX15y9Z+mEWz 91VtmvG/kB2Ja8xi/fl5kOoQM0CVa1iHKmJi7w5CB2J3cKnOHRH2sF9DRK8H+QP128ph pEYtoMhzWQr6kNK+nvBIKoRNrJn/vbXpB6X+lkurQ8sISh3e31idqisj0dV9wha7HMIA Gkz7lv59NuyigeoXgF2SuCrrdE/EnQo1m042Ti/n1HGYyIcr8RwiwAl2oDbmarze7j8z 07SjRKNXgLex7CfxmWwQqemaL3bhxL7Om22UFodrOUJ3M5MqdixH1RoZ6dJ2XktjGour ioog== X-Gm-Message-State: ACrzQf2DHtNy4i5YailT8BSl5038wAOYT392M0tvsvxwqE7f7+Gm2nvB wQpwAux2K4WSaEKQGQ7JRaiygAa7TE6w8lGWHHwolnRu//cI+i17njR52oV6bsPeXrt4HYU8EVV ZO391SNqhJL3/qWp2Tu5Z0Uiq X-Received: by 2002:a05:620a:b51:b0:6cf:68b2:d86e with SMTP id x17-20020a05620a0b5100b006cf68b2d86emr16329431qkg.176.1664267747427; Tue, 27 Sep 2022 01:35:47 -0700 (PDT) X-Received: by 2002:a05:620a:b51:b0:6cf:68b2:d86e with SMTP id x17-20020a05620a0b5100b006cf68b2d86emr16329418qkg.176.1664267747218; Tue, 27 Sep 2022 01:35:47 -0700 (PDT) Received: from [192.168.149.123] (58.254.164.109.static.wline.lns.sme.cust.swisscom.ch. [109.164.254.58]) by smtp.gmail.com with ESMTPSA id f2-20020ac86ec2000000b0035d420c4ba7sm466320qtv.54.2022.09.27.01.35.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Sep 2022 01:35:46 -0700 (PDT) Message-ID: <07014070-5186-ca95-7028-82f77612dedd@redhat.com> Date: Tue, 27 Sep 2022 10:35:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [RFC PATCH 9/9] kvm_main.c: handle atomic memslot update Content-Language: en-US To: David Hildenbrand , kvm@vger.kernel.org Cc: Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , Maxim Levitsky , x86@kernel.org, "H. Peter Anvin" , linux-kernel@vger.kernel.org References: <20220909104506.738478-1-eesposit@redhat.com> <20220909104506.738478-10-eesposit@redhat.com> From: Emanuele Giuseppe Esposito In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_NONE,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 Am 27/09/2022 um 09:46 schrieb David Hildenbrand: > On 09.09.22 12:45, Emanuele Giuseppe Esposito wrote: >> When kvm_vm_ioctl_set_memory_region_list() is invoked, we need >> to make sure that all memslots are updated in the inactive list >> and then swap (preferreably only once) the lists, so that all >> changes are visible immediately. >> >> The only issue is that DELETE and MOVE need to perform 2 swaps: >> firstly replace old memslot with invalid, and then remove invalid. >> > > I'm curious, how would a resize (grow/shrink) or a split be handled? > There are only 4 operations possible in KVM: KVM_MR_{DELETE, MOVE, CREATE, FLAGS_ONLY}. A resize should be implemented in QEMU as DELETE+CREATE. Therefore a resize on memslot X will be implemented as: First pass on the userspace operations: invalidate memslot X; swap_memslot_list(); // NOW it is visible to the guest What guest sees: memslot X is invalid, so MMU keeps retrying the page fault Second pass: create new memslot X delete old memslot X What guest sees: memslot X is invalid, so MMU keeps retrying the page fault Third pass: swap() // 1 for each address space affected What guest sees: new memslot replacing the old one A split is DELETE+CREATE+CREATE, so it's the same: First pass on the userspace operations: invalidate memslot X; swap_memslot_list(); // NOW it is visible to the guest What guest sees: memslot X is invalid, so MMU keeps retrying the page fault Second pass: delete old memslot X create new memslot X1 create new memslot X2 What guest sees: memslot X is invalid, so MMU keeps retrying the page fault Third pass: swap() // 1 for each address space affected What guest sees: two new memslots replacing the old one