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=-9.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 5574DC43463 for ; Thu, 17 Sep 2020 22:07:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 10DB62078B for ; Thu, 17 Sep 2020 22:07:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="OgISkzbS" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726189AbgIQWHv (ORCPT ); Thu, 17 Sep 2020 18:07:51 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:44137 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725874AbgIQWHu (ORCPT ); Thu, 17 Sep 2020 18:07:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1600380469; 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=aViMg+Pc+E39KYInTit03KCHA+7VqkV7P3uI8wkBDXE=; b=OgISkzbScbpqCLS4majy65JC8lyYJSnyqO9/mXeKFjsi82LDyCsgG/Qk75RDwCwij4jv5/ jTfU4GYqyS7HG7AAVEurF+edyVKmA5hG21NAbUI20PgJzuGnFK28Icl1krAc7f1Bt/R2ed vALymO94YOp2eyaxeDvmNiY1ub2AuPc= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-545-brqZ6OWuMAuh19u2m6FVMg-1; Thu, 17 Sep 2020 18:07:44 -0400 X-MC-Unique: brqZ6OWuMAuh19u2m6FVMg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 30B77801AF5; Thu, 17 Sep 2020 22:07:43 +0000 (UTC) Received: from x1.home (ovpn-112-71.phx2.redhat.com [10.3.112.71]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7F19B55761; Thu, 17 Sep 2020 22:07:42 +0000 (UTC) Date: Thu, 17 Sep 2020 16:07:42 -0600 From: Alex Williamson To: Cornelia Huck Cc: Zenghui Yu , , , Subject: Re: [PATCH 2/2] vfio/pci: Remove bardirty from vfio_pci_device Message-ID: <20200917160742.4e4d6efd@x1.home> In-Reply-To: <20200917133537.17af2ef3.cohuck@redhat.com> References: <20200917033128.872-1-yuzenghui@huawei.com> <20200917033128.872-2-yuzenghui@huawei.com> <20200917133537.17af2ef3.cohuck@redhat.com> Organization: Red Hat MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 17 Sep 2020 13:35:37 +0200 Cornelia Huck wrote: > On Thu, 17 Sep 2020 11:31:28 +0800 > Zenghui Yu wrote: > > > It isn't clear what purpose the @bardirty serves. It might be used to avoid > > the unnecessary vfio_bar_fixup() invoking on a user-space BAR read, which > > is not required when bardirty is unset. > > > > The variable was introduced in commit 89e1f7d4c66d ("vfio: Add PCI device > > driver") but never actually used, so it shouldn't be that important. Remove > > it. > > > > Signed-off-by: Zenghui Yu > > --- > > drivers/vfio/pci/vfio_pci_config.c | 7 ------- > > drivers/vfio/pci/vfio_pci_private.h | 1 - > > 2 files changed, 8 deletions(-) > > Yes, it seems to have been write-only all the time. I suspect the intent was that vfio_bar_fixup() could test vdev->bardirty to avoid doing work if no BARs had been written since they were last read. As it is now we regenerate vconfig for all the BARs every time any offset of any of them are read. BARs aren't re-read regularly and config space is not a performance path, but maybe we should instead test if we see any regressions from returning without doing any work in vfio_bar_fixup() if vdev->bardirty is false. Thanks, Alex