From: Tony Krowiak <akrowiak@linux.ibm.com>
To: Halil Pasic <pasic@linux.ibm.com>
Cc: linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, freude@linux.ibm.com,
borntraeger@de.ibm.com, cohuck@redhat.com,
mjrosato@linux.ibm.com, alex.williamson@redhat.com,
kwankhede@nvidia.com, fiuczy@linux.ibm.com,
frankja@linux.ibm.com, david@redhat.com, hca@linux.ibm.com,
gor@linux.ibm.com
Subject: Re: [PATCH v12 12/17] s390/vfio-ap: allow hot plug/unplug of AP resources using mdev device
Date: Mon, 30 Nov 2020 19:18:30 -0500 [thread overview]
Message-ID: <65834705-347c-1e8d-f33f-b64bc2501b37@linux.ibm.com> (raw)
In-Reply-To: <20201201003227.0c3696fc.pasic@linux.ibm.com>
On 11/30/20 6:32 PM, Halil Pasic wrote:
> On Mon, 30 Nov 2020 14:36:10 -0500
> Tony Krowiak <akrowiak@linux.ibm.com> wrote:
>
>>
>> On 11/28/20 8:52 PM, Halil Pasic wrote:
> [..]
>>>> * Unassign adapter from mdev's matrix:
>>>>
>>>> The domain will be hot unplugged from the KVM guest if it is
>>>> assigned to the guest's matrix.
>>>>
>>>> * Assign a control domain:
>>>>
>>>> The control domain will be hot plugged into the KVM guest if it is not
>>>> assigned to the guest's APCB. The AP architecture ensures a guest will
>>>> only get access to the control domain if it is in the host's AP
>>>> configuration, so there is no risk in hot plugging it; however, it will
>>>> become automatically available to the guest when it is added to the host
>>>> configuration.
>>>>
>>>> * Unassign a control domain:
>>>>
>>>> The control domain will be hot unplugged from the KVM guest if it is
>>>> assigned to the guest's APCB.
>>> This is where things start getting tricky. E.g. do we need to revise
>>> filtering after an unassign? (For example an assign_adapter X didn't
>>> change the shadow, because queue XY was missing, but now we unplug domain
>>> Y. Should the adapter X pop up? I guess it should.)
>> I suppose that makes sense at the expense of making the code
>> more complex. It is essentially what we had in the prior version
>> which used the same filtering code for assignment as well as
>> host AP configuration changes.
>>
> Will have to think about it some more. Making the user unplug and
> replug an adapter because at some point it got filtered, but there
> is no need to filter it does not feel right. On the other hand, I'm
> afraid I'm complaining in circles.
>
>>>
>>>> Note: Now that hot plug/unplug is implemented, there is the possibility
>>>> that an assignment/unassignment of an adapter, domain or control
>>>> domain could be initiated while the guest is starting, so the
>>>> matrix device lock will be taken for the group notification callback
>>>> that initializes the guest's APCB when the KVM pointer is made
>>>> available to the vfio_ap device driver.
>>>>
>>>> Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com>
>>>> ---
>>>> drivers/s390/crypto/vfio_ap_ops.c | 190 +++++++++++++++++++++++++-----
>>>> 1 file changed, 159 insertions(+), 31 deletions(-)
>>>>
>>>> diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
>>>> index 586ec5776693..4f96b7861607 100644
>>>> --- a/drivers/s390/crypto/vfio_ap_ops.c
>>>> +++ b/drivers/s390/crypto/vfio_ap_ops.c
>>>> @@ -631,6 +631,60 @@ static void vfio_ap_mdev_manage_qlinks(struct ap_matrix_mdev *matrix_mdev,
>>>> }
>>>> }
>>>>
>>>> +static bool vfio_ap_assign_apid_to_apcb(struct ap_matrix_mdev *matrix_mdev,
>>>> + unsigned long apid)
>>>> +{
>>>> + unsigned long apqi, apqn;
>>>> + unsigned long *aqm = matrix_mdev->shadow_apcb.aqm;
>>>> +
>>>> + /*
>>>> + * If the APID is already assigned to the guest's shadow APCB, there is
>>>> + * no need to assign it.
>>>> + */
>>>> + if (test_bit_inv(apid, matrix_mdev->shadow_apcb.apm))
>>>> + return false;
>>>> +
>>>> + /*
>>>> + * If no domains have yet been assigned to the shadow APCB and one or
>>>> + * more domains have been assigned to the matrix mdev, then use
>>>> + * the domains assigned to the matrix mdev; otherwise, there is nothing
>>>> + * to assign to the shadow APCB.
>>>> + */
>>>> + if (bitmap_empty(matrix_mdev->shadow_apcb.aqm, AP_DOMAINS)) {
>>>> + if (bitmap_empty(matrix_mdev->matrix.aqm, AP_DOMAINS))
>>>> + return false;
>>>> +
>>>> + aqm = matrix_mdev->matrix.aqm;
>>>> + }
>>>> +
>>>> + /* Make sure all APQNs are bound to the vfio_ap driver */
>>>> + for_each_set_bit_inv(apqi, aqm, AP_DOMAINS) {
>>>> + apqn = AP_MKQID(apid, apqi);
>>>> +
>>>> + if (vfio_ap_mdev_get_queue(matrix_mdev, apqn) == NULL)
>>>> + return false;
>>>> + }
>>>> +
>>>> + set_bit_inv(apid, matrix_mdev->shadow_apcb.apm);
>>>> +
>>>> + /*
>>>> + * If we verified APQNs using the domains assigned to the matrix mdev,
>>>> + * then copy the APQIs of those domains into the guest's APCB
>>>> + */
>>>> + if (bitmap_empty(matrix_mdev->shadow_apcb.aqm, AP_DOMAINS))
>>>> + bitmap_copy(matrix_mdev->shadow_apcb.aqm,
>>>> + matrix_mdev->matrix.aqm, AP_DOMAINS);
>>>> +
>>>> + return true;
>>>> +}
>>> What is the rationale behind the shadow aqm empty special handling?
>> The rationale was to avoid taking the VCPUs
>> out of SIE in order to make an update to the guest's APCB
>> unnecessarily. For example, suppose the guest is started
>> without access to any APQNs (i.e., all matrix and shadow_apcb
>> masks are zeros). Now suppose the administrator proceeds to
>> start assigning AP resources to the mdev. Let's say he starts
>> by assigning adapters 1 through 100. The code below will return
>> true indicating the shadow_apcb was updated. Consequently,
>> the calling code will commit the changes to the guest's
>> APCB. The problem there is that in order to update the guest's
>> VCPUs, they will have to be taken out of SIE, yet the guest will
>> not get access to the adapter since no domains have yet been
>> assigned to the APCB. Doing this 100 times - once for each
>> adapter 1-100 - is probably a bad idea.
>>
> Not yanking the VCPUs out of SIE does make a lot of sense. At least
> I understand your motivation now. I will think some more about this,
> but in the meanwhile, please try to answer one more question (see
> below).
>
>>> I.e.
>>> why not simply:
>>>
>>>
>>> static bool vfio_ap_assign_apid_to_apcb(struct ap_matrix_mdev *matrix_mdev,
>>> unsigned long apid)
>>> {
>>> unsigned long apqi, apqn;
>>> unsigned long *aqm = matrix_mdev->shadow_apcb.aqm;
>>>
>>> /*
>>> * If the APID is already assigned to the guest's shadow APCB, there is
>>> * no need to assign it.
>>> */
>>> if (test_bit_inv(apid, matrix_mdev->shadow_apcb.apm))
>>> return false;
>>>
>>> /* Make sure all APQNs are bound to the vfio_ap driver */
>>> for_each_set_bit_inv(apqi, aqm, AP_DOMAINS) {
>>> apqn = AP_MKQID(apid, apqi);
>>>
>>> if (vfio_ap_mdev_get_queue(matrix_mdev, apqn) == NULL)
>>> return false;
>>> }
>>>
>>> set_bit_inv(apid, matrix_mdev->shadow_apcb.apm);
>>>
>>> return true;
> Would
> s/return true/return !bitmap_empty(matrix_mdev->shadow_apcb.aqm,
> AP_DOMAINS)/
> do the trick?
>
> I mean if empty, then we would not commit the APCB, so we would
> not take the vCPUs out of SIE -- see below.
At first glance I'd say yes, it does the trick; but, I need to consider
all possible scenarios. For example, that will work fine when someone
either assigns all of the adapters or all of the domains first, then assigns
the other.
>
>>>> +
>>>> +static void vfio_ap_mdev_hot_plug_adapter(struct ap_matrix_mdev *matrix_mdev,
>>>> + unsigned long apid)
>>>> +{
>>>> + if (vfio_ap_assign_apid_to_apcb(matrix_mdev, apid))
>>>> + vfio_ap_mdev_commit_shadow_apcb(matrix_mdev);
>>>> +}
>>>> +
> [..]
>
> Regards,
> Halil
next prev parent reply other threads:[~2020-12-01 0:20 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-24 21:39 [PATCH v12 00/17] s390/vfio-ap: dynamic configuration support Tony Krowiak
2020-11-24 21:40 ` [PATCH v12 01/17] s390/vfio-ap: move probe and remove callbacks to vfio_ap_ops.c Tony Krowiak
2020-11-26 9:35 ` Halil Pasic
2020-11-24 21:40 ` [PATCH v12 02/17] s390/vfio-ap: decrement reference count to KVM Tony Krowiak
2020-11-26 9:42 ` Halil Pasic
2020-11-24 21:40 ` [PATCH v12 03/17] 390/vfio-ap: use new AP bus interface to search for queue devices Tony Krowiak
2020-11-26 10:34 ` Halil Pasic
2020-11-30 14:48 ` Tony Krowiak
2020-11-24 21:40 ` [PATCH v12 04/17] s390/vfio-ap: No need to disable IRQ after queue reset Tony Krowiak
2020-11-26 13:37 ` Halil Pasic
2020-11-24 21:40 ` [PATCH v12 05/17] s390/vfio-ap: manage link between queue struct and matrix mdev Tony Krowiak
2020-11-26 14:08 ` Halil Pasic
2020-12-14 23:37 ` Tony Krowiak
2020-11-26 14:45 ` Halil Pasic
2020-12-14 23:32 ` Tony Krowiak
2020-11-24 21:40 ` [PATCH v12 06/17] s390/zcrypt: driver callback to indicate resource in use Tony Krowiak
2020-11-24 21:40 ` [PATCH v12 07/17] s390/vfio-ap: implement in-use callback for vfio_ap driver Tony Krowiak
2020-11-26 15:54 ` Halil Pasic
2020-12-15 3:52 ` Tony Krowiak
2020-11-24 21:40 ` [PATCH v12 08/17] s390/vfio-ap: introduce shadow APCB Tony Krowiak
2020-11-29 0:44 ` Halil Pasic
2020-11-24 21:40 ` [PATCH v12 09/17] s390/vfio-ap: sysfs attribute to display the guest's matrix Tony Krowiak
2020-11-29 0:49 ` Halil Pasic
2020-12-16 20:00 ` Tony Krowiak
2020-11-24 21:40 ` [PATCH v12 10/17] s390/vfio-ap: initialize the guest apcb Tony Krowiak
2020-11-29 1:09 ` Halil Pasic
2020-12-16 20:08 ` Tony Krowiak
2020-11-24 21:40 ` [PATCH v12 11/17] s390/vfio-ap: allow assignment of unavailable AP queues to mdev device Tony Krowiak
2020-11-29 1:17 ` Halil Pasic
2020-12-16 20:14 ` Tony Krowiak
2020-12-16 22:09 ` Halil Pasic
2020-11-24 21:40 ` [PATCH v12 12/17] s390/vfio-ap: allow hot plug/unplug of AP resources using " Tony Krowiak
2020-11-29 1:52 ` Halil Pasic
2020-11-30 19:36 ` Tony Krowiak
2020-11-30 23:32 ` Halil Pasic
2020-12-01 0:18 ` Tony Krowiak [this message]
2020-12-01 10:19 ` Halil Pasic
2020-12-01 17:56 ` Halil Pasic
2020-12-01 22:12 ` Tony Krowiak
2020-12-01 23:14 ` Halil Pasic
2020-11-24 21:40 ` [PATCH v12 13/17] s390/vfio-ap: hot plug/unplug queues on bind/unbind of queue device Tony Krowiak
2020-11-24 21:40 ` [PATCH v12 14/17] s390/zcrypt: Notify driver on config changed and scan complete callbacks Tony Krowiak
[not found] ` <20201130101836.0399547c.pasic@linux.ibm.com>
2020-12-09 7:20 ` Harald Freudenberger
2020-12-16 20:32 ` Tony Krowiak
2020-12-16 20:54 ` Tony Krowiak
2020-11-24 21:40 ` [PATCH v12 15/17] s390/vfio-ap: handle host AP config change notification Tony Krowiak
2020-11-24 21:40 ` [PATCH v12 16/17] s390/vfio-ap: handle AP bus scan completed notification Tony Krowiak
2020-11-24 21:40 ` [PATCH v12 17/17] s390/vfio-ap: update docs to include dynamic config support Tony Krowiak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=65834705-347c-1e8d-f33f-b64bc2501b37@linux.ibm.com \
--to=akrowiak@linux.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=fiuczy@linux.ibm.com \
--cc=frankja@linux.ibm.com \
--cc=freude@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mjrosato@linux.ibm.com \
--cc=pasic@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).