lkml.org 
[lkml]   [2022]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v17 06/15] s390/vfio-ap: refresh guest's APCB by filtering APQNs assigned to mdev
On Tue, 11 Jan 2022 16:19:06 -0500
Tony Krowiak <akrowiak@linux.ibm.com> wrote:

> >
> > Also we could probably do the filtering incrementally. In a sense that
> > at a time only so much changes, and we know that the invariant was
> > preserved without that change. But that would probably end up trading
> > complexity for cycles. I will trust your judgment and your tests on this
> > matter.
>
> I am not entirely clear on what you are suggesting. I think you are
> suggesting that there may not be a need to look at every APQN
> assigned to the mdev when an adapter or domain is assigned or
> unassigned or a queue is probed or removed. Maybe you can clarify
> what you are suggesting here.

Exactly. For example if we have the following assigned
adapters:
1, 2, 3
domains:
1, 2, 3
and the operation we are trying to perform is assign domain 4, then it
is sufficient to have a look at the queues with the APQNs (1,4), (2,4)
and (3, 4). We don't have to examine all the 14 queues.

When an unassign dapter is performed, there is no need to do the
re-filtering, because there is nothing that can pop-back or go away. And
on unassign domain is performed, then all we care about are the queues
of that domain on the filtered adapters.

Similarly if after that successful assign the queue (3,4) gets removed
(from vfio_ap) and then added back again and probed, we only have to
look at the queues (3, 1), (3, 2), (3, 3).

But I'm OK with the current design of this. It is certainly conceptually
simpler to say we have a master-copy and we filter that master-copy based
on the very same rules every time something changes. I'm really fine
either way as log as it works well. :D

Regards,
Halil

\
 
 \ /
  Last update: 2022-01-12 12:54    [W:0.155 / U:0.364 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site