<div dir="ltr"><div dir="ltr"><div>From: Harald Freudenberger <<a href="mailto:freude@linux.ibm.com">freude@linux.ibm.com</a>></div><div><br></div><div>BugLink: <a href="http://bugs.launchpad.net/bugs/1799184">http://bugs.launchpad.net/bugs/1799184</a></div><div><br></div><div>The current AP bus, AP devices and AP device drivers implementation</div><div>uses a clearly defined mapping for binding AP devices to AP device</div><div>drivers. So for example a CEX6C queue will always be bound to the</div><div>cex4queue device driver.</div><div><br></div><div>The Linux Device Driver model has no sensitivity for more than one</div><div>device driver eligible for one device type. If there exist more than</div><div>one drivers matching to the device type, simple all drivers are tried</div><div>consecutively.  There is no way to determine and influence the probing</div><div>order of the drivers.</div><div><br></div><div>With KVM there is a need to provide additional device drivers matching</div><div>to the very same type of AP devices. With a simple implementation the</div><div>KVM drivers run in competition to the regular drivers. Whichever</div><div>'wins' a device depends on build order and implementation details</div><div>within the common Linux Device Driver Model and is not</div><div>deterministic. However, a userspace process could figure out which</div><div>device should be bound to which driver and sort out the correct</div><div>binding by manipulating attributes in the sysfs.</div><div><br></div><div>If for security reasons a AP device must not get bound to the 'wrong'</div><div>device driver the sorting out has to be done within the Linux kernel</div><div>by the AP bus code. This patch modifies the behavior of the AP bus</div><div>for probing drivers for devices in a way that two sets of drivers are</div><div>usable. Two new bitmasks 'apmask' and 'aqmask' are used to mark a</div><div>subset of the APQN range for 'usable by the ap bus and the default</div><div>drivers' or 'not usable by the default drivers and thus available for</div><div>alternate drivers like vfio-xxx'. So an APQN which is addressed by</div><div>this masking only the default drivers will be probed. In contrary an</div><div>APQN which is not addressed by the masks will never be probed and</div><div>bound to default drivers but onny to alternate drivers.</div><div><br></div><div>Eventually the two masks give a way to divide the range of APQNs into</div><div>two pools: one pool of APQNs used by the AP bus and the default</div><div>drivers and thus via zcrypt drivers available to the userspace of the</div><div>system. And another pool where no zcrypt drivers are bound to and</div><div>which can be used by alternate drivers (like vfio-xxx) for their</div><div>needs. This division is hot-plug save and makes sure a APQN assigned</div><div>to an alternate driver is at no time somehow exploitable by the wrong</div><div>party.</div><div><br></div><div>The two masks are located in sysfs at /sys/bus/ap/apmask and</div><div>/sys/bus/ap/aqmask.  The mask syntax is exactly the same as the</div><div>already existing mask attributes in the /sys/bus/ap directory (for</div><div>example ap_usage_domain_mask and ap_control_domain_mask).</div><div><br></div><div>By default all APQNs belong to the ap bus and the default drivers:</div><div><br></div><div>  cat /sys/bus/ap/apmask</div><div>  0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</div><div>  cat /sys/bus/ap/aqmask</div><div>  0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</div><div><br></div><div>The masks can be changed at boot time with the kernel command line</div><div>like this:</div><div><br></div><div>  ... ap.apmask=0xffff ap.aqmask=0x40</div><div><br></div><div>This would give these two pools:</div><div><br></div><div>  default drivers pool:    adapter 0 - 15, domain 1</div><div>  alternate drivers pool:  adapter 0 - 15, all but domain 1</div><div><span style="white-space:pre">                       </span>   adapter 16-255, all domains</div><div><br></div><div>The sysfs attributes for this two masks are writeable and an</div><div>administrator is able to reconfigure the assignements on the fly by</div><div>writing new mask values into.  With changing the mask(s) a revision of</div><div>the existing queue to driver bindings is done. So all APQNs which are</div><div>bound to the 'wrong' driver are reprobed via kernel function</div><div>device_reprobe() and thus the new correct driver will be assigned with</div><div>respect of the changed apmask and aqmask bits.</div><div><br></div><div>The mask values are bitmaps in big endian order starting with bit 0.</div><div>So adapter number 0 is the leftmost bit, mask is 0x8000... The sysfs</div><div>attributes accept 2 different formats:</div><div>- Absolute hex string starting with 0x like "0x12345678" does set</div><div>  the mask starting from left to right. If the given string is shorter</div><div>  than the mask it is padded with 0s on the right. If the string is</div><div>  longer than the mask an error comes back (EINVAL).</div><div>- '+' or '-' followed by a numerical value. Valid examples are "+1",</div><div>  "-13", "+0x41", "-0xff" and even "+0" and "-0". Only the addressed</div><div>  bit in the mask is switched on ('+') or off ('-').</div><div><br></div><div>This patch will also be the base for an upcoming extension to the</div><div>zcrypt drivers to be able to provide additional zcrypt device nodes</div><div>with filtering based on ap and aq masks.</div><div><br></div><div>Signed-off-by: Harald Freudenberger <<a href="mailto:freude@linux.ibm.com">freude@linux.ibm.com</a>></div><div>Signed-off-by: Martin Schwidefsky <<a href="mailto:schwidefsky@de.ibm.com">schwidefsky@de.ibm.com</a>></div><div><br></div><div>---</div><div><br></div><div><a href="https://github.com/torvalds/linux/commit/7e0bdbe5c21cb8316a694e46ad5aad339f6894a6">https://github.com/torvalds/linux/commit/7e0bdbe5c21cb8316a694e46ad5aad339f6894a6</a></div></div></div>