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  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:   Tue, 5 Oct 2021 16:09:54 -0700
From:   Si-Wei Liu <siwliu.kernel@...il.com>
To:     Jason Gunthorpe <jgg@...pe.ca>
Cc:     Haakon Bugge <haakon.bugge@...cle.com>,
        Leon Romanovsky <leon@...nel.org>,
        Doug Ledford <dledford@...hat.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        OFED mailing list <linux-rdma@...r.kernel.org>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: Enabling RO on a VF

On Fri, Oct 1, 2021 at 6:02 AM Jason Gunthorpe <jgg@...pe.ca> wrote:
>
> On Fri, Oct 01, 2021 at 11:59:15AM +0000, Haakon Bugge wrote:
> >
> >
> > > On 1 Oct 2021, at 13:54, Jason Gunthorpe <jgg@...pe.ca> wrote:
> > >
> > > On Fri, Oct 01, 2021 at 11:05:15AM +0000, Haakon Bugge wrote:
> > >> Hey,
> > >>
> > >>
> > >> Commit 1477d44ce47d ("RDMA/mlx5: Enable Relaxed Ordering by default
> > >> for kernel ULPs") uses pcie_relaxed_ordering_enabled() to check if
> > >> RO can be enabled. This function checks if the Enable Relaxed
> > >> Ordering bit in the Device Control register is set. However, on a
> > >> VF, this bit is RsvdP (Reserved for future RW
> > >> implementations. Register bits are read-only and must return zero
> > >> when read. Software must preserve the value read for writes to
> > >> bits.).
> > >>
> > >> Hence, AFAICT, RO will not be enabled when using a VF.
> > >>
> > >> How can that be fixed?
> > >
> > > When qemu takes a VF and turns it into a PF in a VM it must emulate
> > > the RO bit and return one
> >
> > I have a pass-through VF:
> >
> > # lspci -s ff:00.0 -vvv
> > ff:00.0 Ethernet controller: Mellanox Technologies MT28800 Family [ConnectX-5 Ex Virtual Function]
> > []
> >               DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
> >                       RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- FLReset-
>
> Like I said, it is a problem in the qemu area..
>
> Jason
Can you clarify why this is a problem in the QEMU area?

Even though Mellanox device might well support it (on VF), there's no
way for QEMU to really know if an arbitrary passthrough device may
support RO. It either has to resort to the host kernel to detect all
PCIe device functions up to the root port throughout the PCIe fabric,
or it may follow PF's enabling status if it is at all capable. I don't
see what QEMU can do by just forcefully emulating the bit?

Not to mention the current implementation only takes care of broken
root port but not the intermediate switches.
https://lore.kernel.org/linux-arm-kernel/MWHPR12MB1600255ACFCD3FB3C80EB8B6C88B0@MWHPR12MB1600.namprd12.prod.outlook.com/

-Siwei

Powered by blists - more mailing lists