[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210615102049.71a3c125.alex.williamson@redhat.com>
Date: Tue, 15 Jun 2021 10:20:49 -0600
From: Alex Williamson <alex.williamson@...hat.com>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: Max Gurtovoy <mgurtovoy@...dia.com>, cohuck@...hat.com,
kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
aviadye@...dia.com, oren@...dia.com, shahafs@...dia.com,
parav@...dia.com, artemp@...dia.com, kwankhede@...dia.com,
ACurrid@...dia.com, cjia@...dia.com, yishaih@...dia.com,
kevin.tian@...el.com, hch@...radead.org, targupta@...dia.com,
shameerali.kolothum.thodi@...wei.com, liulongfang@...wei.com,
yan.y.zhao@...el.com
Subject: Re: [PATCH 09/11] PCI: add matching checks for driver_override
binding
On Tue, 15 Jun 2021 12:04:58 -0300
Jason Gunthorpe <jgg@...dia.com> wrote:
> On Tue, Jun 15, 2021 at 09:00:29AM -0600, Alex Williamson wrote:
>
> > "vfio" override in PCI-core plays out for other override types. Also I
> > don't think dynamic IDs should be handled uniquely, new_id_store()
> > should gain support for flags and userspace should be able to add new
> > dynamic ID with override-only matches to the table. Thanks,
>
> Why? Once all the enforcement is stripped out the only purpose of the
> new flag is to signal a different prepration of modules.alias - which
> won't happen for the new_id path anyhow
Because new_id allows the admin to insert a new pci_device_id which has
been extended to include a flags field and intentionally handling
dynamic IDs differently from static IDs seems like generally a bad
thing. For example, maybe the admin wants to specify nouveau as only
an override match for all 10de: class vga devices. Thanks,
Alex
Powered by blists - more mailing lists