linux-kernel - Re: RFC: (re-)binding the VFIO platform driver to a platform device

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]

Message-ID: <1380654938.10618.30.camel@snotra.buserror.net>
Date:	Tue, 1 Oct 2013 14:15:38 -0500
From:	Scott Wood <scottwood@...escale.com>
To:	Kim Phillips <kim.phillips@...aro.org>
CC:	<linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	<a.motakis@...tualopensystems.com>, Alexander Graf <agraf@...e.de>,
	Alex Williamson <alex.williamson@...hat.com>,
	<stuart.yoder@...escale.com>,
	Wood Scott-B07421 <B07421@...escale.com>,
	Sethi Varun-B16395 <B16395@...escale.com>,
	Bhushan Bharat-R65777 <R65777@...escale.com>,
	Peter Maydell <peter.maydell@...aro.org>,
	Christoffer Dall <christoffer.dall@...aro.org>,
	<santosh.shukla@...aro.org>, <kvm@...r.kernel.org>
Subject: Re: RFC: (re-)binding the VFIO platform driver to a platform device

On Tue, 2013-10-01 at 13:38 -0500, Kim Phillips wrote:
> Hi,
> 
> Santosh and I are having a problem figuring out how to enable binding
> (and re-binding) platform devices to a platform VFIO driver (see
> Antonis' WIP: [1]) in an upstream-acceptable manner.
> 
> Binding platform drivers currently depends on a string match in the
> device node's compatible entry.  On an arndale, one can currently
> rebind the same device to the same driver like so:
> 
> echo 12ce0000.i2c > /sys/bus/platform/drivers/s3c-i2c/12ce0000.i2c/driver/unbind
> echo 12ce0000.i2c > /sys/bus/platform/drivers/s3c-i2c/bind
> 
> And one can bind it to the vfio-dt driver, as Antonis instructs, by
> appending a 'vfio-dt' string to the device tree compatible entry for
> the device.  Then this would work:
> 
> echo 12ce0000.i2c > /sys/bus/platform/drivers/s3c-i2c/12ce0000.i2c/driver/unbind
> echo 12ce0000.i2c > /sys/bus/platform/drivers/vfio-dt/bind
> 
> Consequently, the hack patch below [2] allows any platform device to be
> bound to the vfio-dt driver, without making changes to the device
> tree.  It's a hack because I don't see having any driver name specific
> code in drivers/base/bus.c being upstream acceptable.

Modifying the device tree is the worse part of this.

Is this part of your later suggestion to make compatible writeable after
boot, or are you talking about messing with the device tree before boot
(putting software config in the device tree, among other ickiness)?

> Alternately, device tree compatible entries may be made writeable after
> boot, e.g.:
> 
> echo vfio-platform > /proc/device-tree/i2c\@12CE0000/compatible
> 
> [note s/vfio-dt/vfio-platform/]
> 
> but that would require the vfio-platform module be reloaded, thereby
> unbinding it from any existing devices it was bound to: we're
> seeking a more dynamic solution.

Eww.

Not to mention that the VFIO user might want to know what the compatible
was, or that we might later want to unbind from VFIO and rebind to the
kernel...

> Alex Graf (cc'd) proposed an alternate approach: re-write the driver
> name in the device's sysfs entry:
> 
> echo "vfio-platform" > /sys/bus/platform/devices/101e0000.rtc/driver/driver_name
> 
> The advantage of this approach is that we can achieve the re-bind
> (unbind + bind) as an atomic operation, which alleviates userspace from
> having to coordinate with other device operations (I think VM migration
> is an example case here).
> 
> Note that driver_name currently doesn't exist in sysfs, so it would
> either have to be added, or another means developed to rename the
> driver symlink itself:

I think the ideal interface would be if you could write the sysfs device
name into the vfio bind file (or some new file in the same directory),
and have it claim that device (preferably with an atomic unbind from the
previous driver).  We shouldn't be messing around with compatible
(either modifying it or telling VFIO which compatibles to look for) when
we know the specific devices (not just type of devices) we want to bind.

-Scott



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/