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 X-Spam-Level: X-Spam-Status: No, score=-7.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2BE13C48BE5 for ; Fri, 11 Jun 2021 12:04:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 13332613E9 for ; Fri, 11 Jun 2021 12:04:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231496AbhFKMGD (ORCPT ); Fri, 11 Jun 2021 08:06:03 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:59755 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231553AbhFKMGC (ORCPT ); Fri, 11 Jun 2021 08:06:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1623413044; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SJDmCGSzSoN+SjlCljTi/drpSsUmCLU82T+0nPdBIYI=; b=a4VUTMWLUXYzavM552xRx+NmkhRenreFrVQRMI3mPfdOQGKIBdtEaPgLnT1GOafBsQ9Vqc CWgMkX+IQ962+sq4GkiI8ClHIbMCeTgxujKMhuCf//CIbyqbkMAqOi5tZJmQLdEEfLptfa 8ldfJOwUX4nzGjZmyHSU35Pe2TLQxKk= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-547-5CrPY4-IOD2NjF0WqqYPvw-1; Fri, 11 Jun 2021 08:04:03 -0400 X-MC-Unique: 5CrPY4-IOD2NjF0WqqYPvw-1 Received: by mail-wm1-f70.google.com with SMTP id v25-20020a1cf7190000b0290197a4be97b7so4350505wmh.9 for ; Fri, 11 Jun 2021 05:04:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SJDmCGSzSoN+SjlCljTi/drpSsUmCLU82T+0nPdBIYI=; b=O+iZd8+l1OjpQaeP+riRSBuq31+3igR9L3zEH+NPw6E80x9ZVWSg/GrzC+eI7Rx0+N wGFuziHGIxlDCa7c5iYVyNw4Pi9JvsUZr0k1Ix5imVL5Ux2sdG05cblCkRhUyhqIE2kn pwpzVSvI2pVfucJCVJCosWCiSYe6eNYkLn1euPx2jeDr2FTziPZY3lVY+B1kl9wUnsU7 4doTDdZ/3PDRj10Mfg9RUvcNvDbKK0npzZjzw5SmPcA9YcYZdrCKmampOxHzFR/X5EIG jVQKqC+L8xOfuhkEIvTIQFhqnHfcSZSR8ELchuO7dBgjPCIJx+WmvzcL8Ln351S+mC2w 5MBw== X-Gm-Message-State: AOAM531w+7HLq3ct2Q+xqyiHrJkmGJKxRtugm5+cOH/jXH0Y1Y6OrLbc fvzy0ZggZLlD1iEMkjzhTyKflaOINYbtpU3gpFh0QM1OaW7FZUBTWR63QJoNNwSTPx1M8XcQ5ez o6am5zwJmyYWOQl9VA5X8nA== X-Received: by 2002:a7b:c0cb:: with SMTP id s11mr3607781wmh.21.1623413042168; Fri, 11 Jun 2021 05:04:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzG2XIC2YxHXVTDi+gO8yJwV9JxmgIYE7VFZU1/ddoPOqjwHeITDdMBlqBjpf4Ks7p+wpwf+g== X-Received: by 2002:a7b:c0cb:: with SMTP id s11mr3607733wmh.21.1623413041887; Fri, 11 Jun 2021 05:04:01 -0700 (PDT) Received: from ?IPv6:2001:b07:6468:f312:c8dd:75d4:99ab:290a? ([2001:b07:6468:f312:c8dd:75d4:99ab:290a]) by smtp.gmail.com with ESMTPSA id o20sm11859481wms.3.2021.06.11.05.04.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Jun 2021 05:04:01 -0700 (PDT) Subject: Re: [PATCH v7 1/4] KVM: stats: Separate generic stats from architecture specific ones To: Christian Borntraeger , Jing Zhang , KVM , KVMARM , LinuxMIPS , KVMPPC , LinuxS390 , Linuxkselftest , Marc Zyngier , James Morse , Julien Thierry , Suzuki K Poulose , Will Deacon , Huacai Chen , Aleksandar Markovic , Thomas Bogendoerfer , Paul Mackerras , Janosch Frank , David Hildenbrand , Cornelia Huck , Claudio Imbrenda , Sean Christopherson , Vitaly Kuznetsov , Jim Mattson , Peter Shier , Oliver Upton , David Rientjes , Emanuele Giuseppe Esposito , David Matlack , Ricardo Koller , Krish Sadhukhan References: <20210603211426.790093-1-jingzhangos@google.com> <20210603211426.790093-2-jingzhangos@google.com> <03f3fa03-6f61-7864-4867-3dc332a9d6f3@de.ibm.com> From: Paolo Bonzini Message-ID: Date: Fri, 11 Jun 2021 14:03:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org On 11/06/21 14:00, Christian Borntraeger wrote: > What is the semantics of remote_tlb_flush? I always interpreted it as "number of times the KVM page table management code needed other CPUs to learn about new page tables". Whether the broadcast is done in software or hardware shouldn't matter; either way I suppose there is still some traffic on the bus involved. ARM is also not updating the stat, I'll send a patch for that. Paolo > For the host: > We usually do not do remote TLB flushes in the "IPI with a flush > executed on the remote CPU" sense. > We do have instructions that invalidates table entries and it will take > care of remote TLBs as well (IPTE and IDTE and CRDTE). > This is nice, but on the other side an operating system MUST use these > instruction if the page table might be in use by any CPU. If not, you > can get a delayed access exception machine check if the hardware detect > a TLB/page table incosistency. > Only if you can guarantee that nobody has this page table attached you > can also use a normal store + tlb flush instruction. > > For the guest (and I guess thats what we care about here?) TLB flushes > are almost completely handled by hardware. There is only the set prefix > instruction that is handled by KVM and this flushes the cpu local cache.