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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 07994C433E0 for ; Fri, 31 Jul 2020 18:23:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E4F7A21744 for ; Fri, 31 Jul 2020 18:23:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="jAOAxME0" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387786AbgGaSX5 (ORCPT ); Fri, 31 Jul 2020 14:23:57 -0400 Received: from us-smtp-1.mimecast.com ([207.211.31.81]:23472 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2387695AbgGaSXz (ORCPT ); Fri, 31 Jul 2020 14:23:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1596219833; 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: in-reply-to:in-reply-to:references:references; bh=FNpcdsYn9B2kxIJXPQv8FKNGYI77IPCjCGNgFBGg9TU=; b=jAOAxME0pF6xAYDA2Jdxd1ujI7EihvrXu8ApNU2yhrk25VgOeP5Z/QjlJ6E1FbWcbi7pxU kyEfMbMSOSmZK/4LygESZju4fiRFMGF9kaaBWcCIQHQcJJ12brI/nw5NoEYoFm2ie6xhh+ GgoktZ18Pr6v5fKOPCMd8LV8vx6DxXc= Received: from mail-lf1-f71.google.com (mail-lf1-f71.google.com [209.85.167.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-343-sSMvz-nzO8euI5_g7tMsdQ-1; Fri, 31 Jul 2020 14:23:50 -0400 X-MC-Unique: sSMvz-nzO8euI5_g7tMsdQ-1 Received: by mail-lf1-f71.google.com with SMTP id j22so6377383lfg.21 for ; Fri, 31 Jul 2020 11:23:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FNpcdsYn9B2kxIJXPQv8FKNGYI77IPCjCGNgFBGg9TU=; b=bjrtPhX5yfELEyUNjXP/8LA6gYNjedK/Sqp+Q3zdSzhwUgSKFawL2FbCZ7hatk/vET nKvn8OytOe8tIZeAAowXXOJzjv2tOQNB6PFXQGIvFRND5Rl/DtSZ8WTRV+q0RpNY3VlG IfTrgpde1S7LrorRzGF4oq004e+c70Uz2CX1hF8ZuQAC8Y0bKh+HhoSdg+ZsyARbz2ok 9negLYjziTUMiJFOj6c91CwnDZAq6nZXDCDF9zZAGqQASs5mqcJrY2GkrnsNUNrKDx5g C9N2HDVCNg8BVf+eyQ8kMHWa0SZB5ZRMr+yfDfHlYByX3KPbBk0iHoYvugcD5z82ZnY5 u8Jg== X-Gm-Message-State: AOAM531imENiuPxBrdvqxaoZFlJIZWdMF2dZQXvS/5dzACdr4TiayNWY GNmQ1GcjYlFvDneVrZpPM+EsLmPk3DhrrqlkvCIJ+EYwx+aPkrS6V67MhHwYZJz3k1fQbpXAG0F bKLlI/HEq/eRR8OkJA+ecEvJzSTQn X-Received: by 2002:a2e:9b92:: with SMTP id z18mr2632607lji.364.1596219828920; Fri, 31 Jul 2020 11:23:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy4Ant7fRiaPouV8KSdgTTmMLlIjwSIMUXrC6ApBECDS2mEDf33c4K66gE4HFkxWsG1WUkVTH6tWl9p/Sj0yXU= X-Received: by 2002:a2e:9b92:: with SMTP id z18mr2632592lji.364.1596219828575; Fri, 31 Jul 2020 11:23:48 -0700 (PDT) MIME-Version: 1.0 References: <20200730193510.578309-1-jusual@redhat.com> <873658kpj2.fsf@vitty.brq.redhat.com> In-Reply-To: <873658kpj2.fsf@vitty.brq.redhat.com> From: Julia Suvorova Date: Fri, 31 Jul 2020 20:23:37 +0200 Message-ID: Subject: Re: [PATCH] KVM: x86: Use MMCONFIG for all PCI config space accesses To: Vitaly Kuznetsov Cc: Andy Shevchenko , "open list:VFIO DRIVER" , Linux Kernel Mailing List , Bjorn Helgaas , "Michael S. Tsirkin" , Matthew Wilcox , Sean Christopherson , Paolo Bonzini , Thomas Gleixner Content-Type: text/plain; charset="UTF-8" Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Fri, Jul 31, 2020 at 11:22 AM Vitaly Kuznetsov wrote: > > Andy Shevchenko writes: > > > On Thu, Jul 30, 2020 at 10:37 PM Julia Suvorova wrote: > >> > >> Using MMCONFIG instead of I/O ports cuts the number of config space > >> accesses in half, which is faster on KVM and opens the door for > >> additional optimizations such as Vitaly's "[PATCH 0/3] KVM: x86: KVM > >> MEM_PCI_HOLE memory": > > > >> https://lore.kernel.org/kvm/20200728143741.2718593-1-vkuznets@redhat.com > > > > You may use Link: tag for this. > > > >> However, this change will not bring significant performance improvement > >> unless it is running on x86 within a hypervisor. Moreover, allowing > >> MMCONFIG access for addresses < 256 can be dangerous for some devices: > >> see commit a0ca99096094 ("PCI x86: always use conf1 to access config > >> space below 256 bytes"). That is why a special feature flag is needed. > >> > >> Introduce KVM_FEATURE_PCI_GO_MMCONFIG, which can be enabled when the > >> configuration is known to be safe (e.g. in QEMU). > > > > ... > > > >> +static int __init kvm_pci_arch_init(void) > >> +{ > >> + if (raw_pci_ext_ops && > >> + kvm_para_has_feature(KVM_FEATURE_PCI_GO_MMCONFIG)) { > > > > Better to use traditional pattern, i.e. > > if (not_supported) > > return bail_out; > > > > ...do useful things... > > return 0; > > > >> + pr_info("PCI: Using MMCONFIG for base access\n"); > >> + raw_pci_ops = raw_pci_ext_ops; > >> + return 0; > >> + } > > > >> + return 1; > > > > Hmm... I don't remember what positive codes means there. Perhaps you > > need to return a rather error code? > > If I'm reading the code correctly, > > pci_arch_init() has the following: > > if (x86_init.pci.arch_init && !x86_init.pci.arch_init()) > return 0; > > > so returning '1' here means 'continue' and this seems to be > correct. (E.g. Hyper-V's hv_pci_init() does the same). What I'm not sure > about is 'return 0' above as this will result in skipping the rest of > pci_arch_init(). Was this desired or should we return '1' in both cases? This is intentional because pci_direct_init() is about to overwrite raw_pci_ops. And since QEMU doesn't have anything in pciprobe_dmi_table, it is safe to skip it. Best regards, Julia Suvorova.