All of lore.kernel.org
 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:19 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.