linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Halil Pasic <pasic@linux.ibm.com>
To: Tony Krowiak <akrowiak@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: Tue, 1 Dec 2020 11:19:14 +0100	[thread overview]
Message-ID: <20201201111914.25a80561.pasic@linux.ibm.com> (raw)
In-Reply-To: <65834705-347c-1e8d-f33f-b64bc2501b37@linux.ibm.com>

On Mon, 30 Nov 2020 19:18:30 -0500
Tony Krowiak <akrowiak@linux.ibm.com> wrote:

> >>>> +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.

Maybe I can help you. The only caveat I have in mind is the show of the
guest_matrix attribute. We probably don't want to display adapters
without domains and vice-versa. But that can be easily handled with
a flag.

Regards,
Halil

  reply	other threads:[~2020-12-01 10: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
2020-12-01 10:19           ` Halil Pasic [this message]
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=20201201111914.25a80561.pasic@linux.ibm.com \
    --to=pasic@linux.ibm.com \
    --cc=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 \
    /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).