On 02.07.2018 18:28, Halil Pasic wrote: > > > On 06/29/2018 11:11 PM, Tony Krowiak wrote: >> This patch provides documentation describing the AP architecture and >> design concepts behind the virtualization of AP devices. It also >> includes an example of how to configure AP devices for exclusive >> use of KVM guests. >> >> Signed-off-by: Tony Krowiak <akrowiak@xxxxxxxxxxxxx> >> --- > [..] >> + >> +Reserve APQNs for exclusive use of KVM guests >> +--------------------------------------------- >> +The following block diagram illustrates the mechanism by which APQNs are >> +reserved: >> + >> + +------------------+ >> + remove | | unbind >> + +------------------->+ cex4queue driver +<-----------+ >> + | | | | >> + | +------------------+ | >> + | | >> + | | >> + | | >> ++--------+---------+ register +------------------+ +-----+------+ >> +| +<---------+ | bind | | >> +| ap_bus | | vfio_ap driver +<-----+ admin | >> +| +--------->+ | | | >> ++------------------+ probe +---+--------+-----+ +------------+ >> + | | >> + create | | store APQN >> + | | >> + v v >> + +---+--------+-----+ >> + | | >> + | matrix device | >> + | | >> + +------------------+ >> + >> +The process for reserving an AP queue for use by a KVM guest is: >> + >> +* The vfio-ap driver during its initialization will perform the following: >> + * Create the 'vfio_ap' root device - /sys/devices/vfio_ap >> + * Create the 'matrix' device in the 'vfio_ap' root >> + * Register the matrix device with the device core >> +* Register with the ap_bus for AP queue devices of type 10 devices (CEX4 and >> + newer) and to provide the vfio_ap driver's probe and remove callback >> + interfaces. The reason why older devices are not supported is because there >> + are no systems available on which to test. >> +* The admin unbinds queue cc.qqqq from the cex4queue device driver. This results >> + in the ap_bus calling the the device driver's remove interface which >> + unbinds the cc.qqqq queue device from the driver. > > What if the queue cc.qqqq is already in use? AFAIU unbind is almost as radical as > pulling a cable. What is the proper procedure an admin should follow before doing > the unbind? What do you mean on this level with 'in use'? A unbind destroys the association between device and driver. There is no awareness of 'in use' or 'not in use' on this level. This is a hard unbind. > >> +* The admin binds the cc.qqqq queue to the vfio_ap device driver. This results >> + in the ap_bus calling the device vfio_ap driver's probe interface to bind >> + queue cc.qqqq to the driver. The vfio_ap device driver will store the APQN for >> + the queue in the matrix device >> + > [..] > > -- > To unsubscribe from this list: send the line "unsubscribe linux-s390" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html >
