On 4/27/20 11:17 AM, Halil Pasic wrote:
On Mon, 27 Apr 2020 15:05:23 +0200
Harald Freudenberger <freude@xxxxxxxxxxxxx> wrote:
On 24.04.20 05:57, Halil Pasic wrote:
On Tue, 7 Apr 2020 15:20:01 -0400
Tony Krowiak <akrowiak@xxxxxxxxxxxxx> wrote:
Rather than looping over potentially 65535 objects, let's store the
structures for caching information about queue devices bound to the
vfio_ap device driver in a hash table keyed by APQN.
@Harald:
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
Hi 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.
I'm a bit confused. Doesn't your code loop first trough the ap_card
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?
The code you reference, _zcrypt_send_ep11_cprb(), does loop through
each queue associated with each card, but it doesn't appear to be
looking for
a queue with a particular APQN. It appears to be looking for a queue
meeting a specific set of conditions. At least that's my take after
taking a very
brief look at the code, so I'm not sure that applies here.
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.
