From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 44289C0502C for ; Sat, 27 Aug 2022 08:29:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=jg2mmIcgU6lY2hyDQiw+YMbiKe2nj3PkNHbfbyVIiOQ=; b=dC2Jqd6241gZku WK0Q4Cuf+s3uZjuBGZenWPCDigUdeyX4p07TKiQKVFf3yAOlWZyMQ87Zv99Ogqw2jEmBRC/kiL4rN lAy9TRdrCX7WUfIlZywdztQrkInBea+MWgAmhlGvieKDk09n4iLbP21dM+VtU1ivrwA9Mh2wXJ6da wsSbxiRxB454JD+NfXTzv4xadgaIuMFU+YaRsyn4AtpEiX3heTqhIaXAda/Lz8pnk5iq1udT7SXLs a8Fk4V7M5nPzCISASkKR0J0nWmXb4LI5UP4E6tRuozurPzPfWsfvjgYt14hB0fZMOiEcRWiyOMJlU eanaCa947ZmsSdHruvzQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oRr9y-005oIK-0D; Sat, 27 Aug 2022 08:27:18 +0000 Received: from mail-ed1-x52a.google.com ([2a00:1450:4864:20::52a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oRr9u-005oB5-OJ for linux-arm-kernel@lists.infradead.org; Sat, 27 Aug 2022 08:27:16 +0000 Received: by mail-ed1-x52a.google.com with SMTP id w20so4578208edd.10 for ; Sat, 27 Aug 2022 01:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc; bh=db6wHPl1NoBxSkqFEqmoNM4w13Oy0TZZkviyKHiod6c=; b=UEYLobTe2AZYd65vehbSh24XDhaWFDZNCGL1gdVQxc452u7u2Q4Y0f66RZocX0c5TR DdJwU7CRlQgFC6BGI+qrfrE8odV1ul43ApbvWCBwVJ+CO5ykyfdKL69XWCEz4AxBVoPc Fw9/BZpE/pwvSNqV+U8bI4UFaXmNWqGWUpCFIcgHDmb/R5YJHvw+l1Nl4PI62pOc0Mlu G6Xxx2tmIx2MgPkjxhb9Qr8ZtxLsw5z8IGCfxtj4gjhzdE7BqdYB4NS6TbXn8rmeHOgA wuLPmYOYHGXF2RHYZcgbY4nK+iZs8S8bbVCuzl21nt3v+hkpld1DBAXs+elsDk4x4Ohv QRlw== 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 :sender:x-gm-message-state:from:to:cc; bh=db6wHPl1NoBxSkqFEqmoNM4w13Oy0TZZkviyKHiod6c=; b=qxhLAgLrutM2cCbSgP+X+hNzI2aC/Z5MMisCrfJ1WQZjaatVIwuOqdiTJ/rGEXGjlV MCEH6ESqcpsMaQBLt6aoSCkg1cnHKcDpznNzD76SkTF+3m7tWHqwFSw/5y7NgCDAjoDe EOS3UX4Yuu9dhXCSRGsx/dyQeZR/3SZDPEPBeOG1vU1NQY9lyuxM9sc9YQjfM7A9lJRy Y42IRYJCpj6V/AX7xoGK/XfxcpfgTjs7WmD/OGmRr8G0XVODIIQSpuZCbVzbAW6vcD0h 4XHH+w2lCB2shrOdQISyEVIy8yKtUywLWHBj2ID/fhIcShSF1wYvuYlf+X8oh2Do+AjP ID4w== X-Gm-Message-State: ACgBeo12CpgVX2UvlhegTWQ3xbTlnXhVz1cGfm/dRNFDE0ImXP1sMPKD fyY2qgxkHb3WxNGzgXUDlVM= X-Google-Smtp-Source: AA6agR7k4MkhXbRXPVNIpqB7niZw9Vuq4+jhvWLePL+17JoEYc9ENHX7DdgLIO1WI1Mrtg/N6ODRPw== X-Received: by 2002:a05:6402:71a:b0:447:ebb2:18f2 with SMTP id w26-20020a056402071a00b00447ebb218f2mr4862760edx.408.1661588831315; Sat, 27 Aug 2022 01:27:11 -0700 (PDT) Received: from ?IPV6:2001:b07:6468:f312:5e2c:eb9a:a8b6:fd3e? ([2001:b07:6468:f312:5e2c:eb9a:a8b6:fd3e]) by smtp.googlemail.com with ESMTPSA id m18-20020a056402511200b0043d5ead65a6sm2485422edd.84.2022.08.27.01.27.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 27 Aug 2022 01:27:10 -0700 (PDT) Message-ID: <79cc1418-2448-6a80-e4b8-2041f94c419e@redhat.com> Date: Sat, 27 Aug 2022 10:27:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: [PATCH v1 1/5] KVM: arm64: Enable ring-based dirty memory tracking Content-Language: en-US To: Marc Zyngier Cc: Peter Xu , Gavin Shan , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, corbet@lwn.net, james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, catalin.marinas@arm.com, will@kernel.org, shuah@kernel.org, seanjc@google.com, dmatlack@google.com, bgardon@google.com, ricarkol@google.com, zhenyzha@redhat.com, shan.gavin@gmail.com References: <20220819005601.198436-1-gshan@redhat.com> <20220819005601.198436-2-gshan@redhat.com> <87lerkwtm5.wl-maz@kernel.org> <41fb5a1f-29a9-e6bb-9fab-4c83a2a8fce5@redhat.com> <87fshovtu0.wl-maz@kernel.org> <171d0159-4698-354b-8b2f-49d920d03b1b@redhat.com> <87bksawz0w.wl-maz@kernel.org> <878rnewpaw.wl-maz@kernel.org> <9e7cb09c-82c5-9492-bccd-5511f5bede26@redhat.com> <8735djvwbu.wl-maz@kernel.org> From: Paolo Bonzini In-Reply-To: <8735djvwbu.wl-maz@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220827_012714_824222_93E7AECF X-CRM114-Status: GOOD ( 19.91 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 8/26/22 17:49, Marc Zyngier wrote: >> Agreed, but that's a problem for userspace to solve. If userspace >> wants to reset the fields in different CPUs, it has to synchronize >> with its own invoking of the ioctl. > > userspace has no choice. It cannot order on its own the reads that the > kernel will do to *other* rings. Those reads will never see KVM_DIRTY_GFN_F_RESET in the flags however, if userspace has never interacted with the ring. So there will be exactly one read on those rings, and there's nothing to reorder. If that's too tricky and you want to add a load-acquire I have no objection though. It also helps avoiding read-read reordering between one entry's flags to the next one's, so it's a good idea to have it anyway. >> The main reason why I preferred a global KVM_RESET_DIRTY_RINGS ioctl >> was because it takes kvm->slots_lock so the execution would be >> serialized anyway. Turning slots_lock into an rwsem would be even >> worse because it also takes kvm->mmu_lock (since slots_lock is a >> mutex, at least two concurrent invocations won't clash with each other >> on the mmu_lock). > > Whatever the reason, the behaviour should be identical on all > architectures. As is is, it only really works on x86, and I contend > this is a bug that needs fixing. > > Thankfully, this can be done at zero cost for x86, and at that of a > set of load-acquires on other architectures. Yes, the global-ness of the API is orthogonal to the memory ordering issue. I just wanted to explain why a per-vCPU API probably isn't going to work great. Paolo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel