On Mon, 27 Apr 2020 15:05:23 +0200
Harald Freudenberger <freude@xxxxxxxxxxxxx> wrote:
On 24.04.20 05:57, Halil Pasic wrote:I'm a bit confused. Doesn't your code loop first trough the ap_card
On Tue, 7 Apr 2020 15:20:01 -0400Hi Halil
Tony Krowiak <akrowiak@xxxxxxxxxxxxx> wrote:
Rather than looping over potentially 65535 objects, let's store the@Harald:
structures for caching information about queue devices bound to the
vfio_ap device driver in a hash table keyed by APQN.
Would it make sense to make the efficient lookup of an apqueue base
on its APQN core AP functionality instead of each driver figuring it out
on it's own?
If I'm not wrong the zcrypt device/driver(s) must the problem of
looking up a queue based on its APQN as well.
For instance struct ep11_cprb has a target_id filed
(arch/s390/include/uapi/asm/zcrypt.h).
Regards,
Halil
no, the zcrypt drivers don't have this problem. They build up their own device object which
includes a pointer to the base ap device.
objects to find the APID portion of the APQN, and then loop the queue
list of the matching card to find the right ap_queue object? Or did I
miss something? Isn't that what _zcrypt_send_ep11_cprb() does? Can you
point me to the code that avoids the lookup (by apqn) for zcrypt?
If you look at the new function of vfio_ap_get_queue(unsigned long apqn)
it basically about finding the queue based on the apqn, with the
difference that it is vfio specific.
Regards,
Halil
However, this is not a big issue, as the ap_bus holds a list of ap_card objects and within each
ap_card object there exists a list of ap_queues.