[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <49b11ac2-2230-ad74-1583-c6a57f8b31e3@linux.ibm.com>
Date: Mon, 2 Jul 2018 18:28:42 +0200
From: Halil Pasic <pasic@...ux.ibm.com>
To: Tony Krowiak <akrowiak@...ux.vnet.ibm.com>,
linux-s390@...r.kernel.org, linux-kernel@...r.kernel.org,
kvm@...r.kernel.org
Cc: freude@...ibm.com, schwidefsky@...ibm.com,
heiko.carstens@...ibm.com, borntraeger@...ibm.com,
cohuck@...hat.com, kwankhede@...dia.com,
bjsdjshi@...ux.vnet.ibm.com, pbonzini@...hat.com,
alex.williamson@...hat.com, pmorel@...ux.vnet.ibm.com,
alifm@...ux.vnet.ibm.com, mjrosato@...ux.vnet.ibm.com,
jjherne@...ux.vnet.ibm.com, thuth@...hat.com,
pasic@...ux.vnet.ibm.com, berrange@...hat.com,
fiuczy@...ux.vnet.ibm.com, buendgen@...ibm.com,
Tony Krowiak <akrowiak@...ux.ibm.com>
Subject: Re: [PATCH v6 21/21] s390: doc: detailed specifications for AP
virtualization
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@...ux.ibm.com>
> ---
[..]
> +
> +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?
> +* 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
> +
[..]
Powered by blists - more mailing lists