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 7DFCEC48BE0 for ; Fri, 11 Jun 2021 12:04:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 577ED613CF for ; Fri, 11 Jun 2021 12:04:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231579AbhFKMGF (ORCPT ); Fri, 11 Jun 2021 08:06:05 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:58371 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231553AbhFKMGD (ORCPT ); Fri, 11 Jun 2021 08:06:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1623413045; 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=e1pg4RtDKVJIWrZIsPDAdiIzKDQiTPlQ9kD3wa/bsALNmGpdZE3wA9Lcyf1wS250tQQMX2 umMi+zEbn+jb4EcswPc41ssfq461rWnWkRKJYWpnMu2NADmWyxNtW1lIiOFC45a1XWruVc 446ycv4RKtAanjoSYa+NnIxmgqaS4Vc= 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-64-5Q0wEw-UOg2tBgX8V-sknA-1; Fri, 11 Jun 2021 08:04:03 -0400 X-MC-Unique: 5Q0wEw-UOg2tBgX8V-sknA-1 Received: by mail-wm1-f70.google.com with SMTP id n8-20020a05600c3b88b02901b6e5bcd841so1631748wms.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=I0u+dhetDtQDZWoyUb6DckXQGcxVs6FLHtBlW8HlLAn/n9tFHUaC20J277FM2//TC7 s3heKc0H6+PzN9QAAAhxh6cCsm+tTHVQp4QJbaDJMJow1IKXavYckSV7NpmIIW8Ss63k f2iBVnHLNBUHs23ZEhsMYxsO2YP1c0/EN9qpTlFWBqtKxq1I4vvfKSEg3jYhDVie0o7M iqCLCBb03sbmqHRhJy4mB/uxjbucU1ZIIq+E6vCLAAZlDRjZGAEfzKkUH5K7/+arxlaH /URhwSIjH0TrTf6uU6QAYzG9UEPQ7/KOvv5d/uG6bWpsCAc3G9HEbgluipk2XNWgyYZ7 vawg== X-Gm-Message-State: AOAM532yWy9V/valTixBDVXQtR6xGPdzJyArTU1k9Ns6TIl2zvuU0row MFCvs6zSLjanpTO1Xg/yzeghw1nTT4aYDFtRKTvq2FZ+5cS192hLrMsaHOHVn8CQKOTYHi/5spL V9RUZY8q8P+Nf X-Received: by 2002:a7b:c0cb:: with SMTP id s11mr3607780wmh.21.1623413042166; 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: kvm@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.