lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 30 Jul 2020 22:50:29 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Julia Suvorova <jusual@...hat.com>
Cc:     "open list:VFIO DRIVER" <kvm@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Bjorn Helgaas <helgaas@...nel.org>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Matthew Wilcox <willy@...radead.org>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] KVM: x86: Use MMCONFIG for all PCI config space accesses

On Thu, Jul 30, 2020 at 10:37 PM Julia Suvorova <jusual@...hat.com> 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?

> +}

-- 
With Best Regards,
Andy Shevchenko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ