lkml.org 
[lkml]   [2021]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 8/9] vfio/pci: export nvlink2 support into vendor vfio_pci drivers
    On Mon, 29 Mar 2021 17:10:53 -0600
    Alex Williamson <alex.williamson@redhat.com> wrote:

    > On Tue, 23 Mar 2021 16:32:13 -0300
    > Jason Gunthorpe <jgg@nvidia.com> wrote:
    >
    > > On Mon, Mar 22, 2021 at 10:40:16AM -0600, Alex Williamson wrote:

    > > > So unless you want to do some bitkeeper archaeology, we've always
    > > > allowed driver probes to fail and fall through to the next one, not
    > > > even complaining with -ENODEV. In practice it hasn't been an issue
    > > > because how many drivers do you expect to have that would even try to
    > > > claim a device.
    > >
    > > Do you know of anything using this ability? It might be helpful
    >
    > I don't.

    I've been trying to remember why I added that patch to ignore all
    errors (rather than only -ENODEV), but I suspect it might have been
    related to the concurrent probing stuff I tried to implement back then.
    The one instance of drivers matching to the same id I recall (s390
    ctc/lcs) is actually not handled on the individual device level, but in
    the meta ccwgroup driver; I don't remember anything else in the s390
    case.

    >
    > > > Ordering is only important when there's a catch-all so we need to
    > > > figure out how to make that last among a class of drivers that will
    > > > attempt to claim a device. The softdep is a bit of a hack to do
    > > > that, I'll admit, but I don't see how the alternate driver flavor
    > > > universe solves having a catch-all either.
    > >
    > > Haven't entirely got there yet, but I think the catch all probably has
    > > to be handled by userspace udev/kmod in some way, as it is the only
    > > thing that knows if there is a more specific module to load. This is
    > > the biggest problem..
    > >
    > > And again, I feel this is all a big tangent, especially now that HCH
    > > wants to delete the nvlink stuff we should just leave igd alone.
    >
    > Determining which things stay in vfio-pci-core and which things are
    > split to variant drivers and how those variant drivers can match the
    > devices they intend to support seems very inline with this series. If
    > igd stays as part of vfio-pci-core then I think we're drawing a
    > parallel to z-pci support, where a significant part of that support is
    > a set of extra data structures exposed through capabilities to support
    > userspace use of the device. Therefore extra regions or data
    > structures through capabilities, where we're not changing device
    > access, except as required for the platform (not the device) seem to be
    > things that fit within the core, right? Thanks,
    >
    > Alex

    As we are only talking about extra data governed by a capability, I
    don't really see a problem with keeping it in the vfio core.

    For those devices that need more specialized treatment, maybe we need
    some kind of priority-based matching? I.e., if we match a device with
    drivers, start with the one with highest priority (the specialized
    one), and have the generic driver at the lowest priority. A
    higher-priority driver added later one should not affect already bound
    devices (and would need manual intervention again.)

    [I think this has come up in other places in the past as well, but I
    don't have any concrete pointers handy.]

    \
     
     \ /
      Last update: 2021-04-01 20:32    [W:3.242 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site