On 2013-12-09 19:58, Kim Phillips wrote: > On Thu, 5 Dec 2013 16:38:15 -0600 > Scott Wood <scottwood@xxxxxxxxxxxxx> wrote: > >> On Thu, 2013-12-05 at 17:45 +0000, Kim Phillips wrote: >>> On Tue, 03 Dec 2013 16:34:33 +0100 >>> Jan Kiszka <jan.kiszka@xxxxxxxxxxx> wrote: >>> >>>> On 2013-12-03 13:34, Kim Phillips wrote: >>>>> VFIO supports pass-through of devices to user space - for sake >>>>> of illustration, say a PCI e1000 device: >>>>> >>>>> - the e1000 is first unbound from the PCI e1000 driver via sysfs >>>>> - the vfio-pci driver is told via new_id that it now handles e1000 devices >>>>> - the e1000 is explicitly bound to vfio-pci through sysfs >>>>> >>>>> However, now we have two drivers in the system that both handle e1000 >>>>> devices. A hotplug event could then occur and it is ambiguous as to which >>>>> driver will claim the device. The desired semantics is that vfio-pci is >>>>> only bound to devices by explicit request in sysfs. This patch makes this >>>>> possible by introducing a sysfs_bind_only flag in struct device_driver. >>>>> >>>>> Signed-off-by: Stuart Yoder <stuart.yoder@xxxxxxxxxxxxx> >>>>> Signed-off-by: Kim Phillips <kim.phillips@xxxxxxxxxx> >>>>> --- >>>>> rebased onto 3.13-rc2, and reposted from first submission which >>>>> recieved no comments: >>>>> >>>>> https://lkml.org/lkml/2013/10/11/53 >>>>> >>>>> drivers/base/dd.c | 5 ++++- >>>>> include/linux/device.h | 2 ++ >>>>> 2 files changed, 6 insertions(+), 1 deletion(-) >>>>> >>>>> diff --git a/drivers/base/dd.c b/drivers/base/dd.c >>>>> index 0605176..b83b16d 100644 >>>>> --- a/drivers/base/dd.c >>>>> +++ b/drivers/base/dd.c >>>>> @@ -389,7 +389,7 @@ static int __device_attach(struct device_driver *drv, void *data) >>>>> { >>>>> struct device *dev = data; >>>>> >>>>> - if (!driver_match_device(drv, dev)) >>>>> + if (drv->sysfs_bind_only || !driver_match_device(drv, dev)) >>>>> return 0; >>>>> >>>>> return driver_probe_device(drv, dev); >>>>> @@ -476,6 +476,9 @@ static int __driver_attach(struct device *dev, void *data) >>>>> */ >>>>> int driver_attach(struct device_driver *drv) >>>>> { >>>>> + if (drv->sysfs_bind_only) >>>>> + return 0; >>>>> + >>>>> return bus_for_each_dev(drv->bus, NULL, drv, __driver_attach); >>>>> } >>>>> EXPORT_SYMBOL_GPL(driver_attach); >>>>> diff --git a/include/linux/device.h b/include/linux/device.h >>>>> index 952b010..ed441d1 100644 >>>>> --- a/include/linux/device.h >>>>> +++ b/include/linux/device.h >>>>> @@ -200,6 +200,7 @@ extern struct klist *bus_get_device_klist(struct bus_type *bus); >>>>> * @owner: The module owner. >>>>> * @mod_name: Used for built-in modules. >>>>> * @suppress_bind_attrs: Disables bind/unbind via sysfs. >>>>> + * @sysfs_bind_only: Only allow bind/unbind via sysfs. >>>>> * @of_match_table: The open firmware table. >>>>> * @acpi_match_table: The ACPI match table. >>>>> * @probe: Called to query the existence of a specific device, >>>>> @@ -233,6 +234,7 @@ struct device_driver { >>>>> const char *mod_name; /* used for built-in modules */ >>>>> >>>>> bool suppress_bind_attrs; /* disables bind/unbind via sysfs */ >>>>> + bool sysfs_bind_only; /* only allow bind/unbind via sysfs */ >>>>> >>>>> const struct of_device_id *of_match_table; >>>>> const struct acpi_device_id *acpi_match_table; >>>> >>>> I think I only discussed this with Stuart in person at the KVM Forum: >>>> Why not deriving the property "sysfs bind only" from the fact that a >>>> device does wild-card binding? Are there use cases that benefit from >>>> decoupling both features? >>> >>> you mean merge the two new flags sysfs_bind_only and platform driver's >>> match_any_dev into one new single driver flag, right? good question. >> >> What would combining them solve, other than making it more likely that >> Greg complains about the wildcard because it would no longer be handled >> at the bus level where all the other matching goes on? >> >> They are logically separate things. That doesn't change just because we >> currently plan to use them together. > > Jan? Given the above, what would be the advantage of merging > sysfs_bind_only and (PCI drivers' PCI_ANY_ID and platform drivers' > match_any_dev)? That you cannot configure (likely) meaningless or even harmful (bind-any + auto-bind) configurations. I didn't follow if Greg expressed his opinion on this or a similar scenario before. If he prefers separate knobs for a certain reason, he likely wins. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
