On Wed, 12 Jun 2024 16:04:15 +0200
Thomas Huth wrote:
> On 11/06/2024 23.47, Halil Pasic wrote:
> > Commit e3e9bda38e6d ("s390/virtio_ccw: use DMA handle from DMA API")
> > broke configuration change notifications for virtio-ccw by putting the
> > DMA address o
uot;s390/virtio_ccw: use DMA handle from DMA API")
Signed-off-by: Halil Pasic
---
I know that checkpatch.pl complains about a missing 'Closes' tag.
Unfortunately I don't have an appropriate URL at hand. @Sebastian,
@Boqiao: do you have any suggetions?
---
drivers/s390/virtio/virtio_ccw.c
On Tue, 6 Apr 2021 11:31:09 -0400
Tony Krowiak wrote:
> Tony Krowiak (13):
> s390/vfio-ap: fix circular lockdep when setting/clearing crypto masks
The subsequent patches, re introduce this circular locking dependency
problem. See my kernel messages for the details. The link we severe
in the
On Wed, 31 Mar 2021 11:22:43 -0400
Tony Krowiak wrote:
> Change log v13-v14:
> --
When testing I've experienced this kernel panic.
[ 4422.479706] vfio_ap matrix: MDEV: Registered
[ 4422.516999] vfio_mdev b2013234-18b2-49bf-badd-a4be9c78b120: Adding to iommu
group 1
[
ue. Functions that require
> access to matrix_mdev->kvm will sleep on the wait queue until they are
> awakened at which time they can safely access the matrix_mdev->kvm
> field.
>
> Fixes: f21916ec4826 ("s390/vfio-ap: clean up vfio_ap resources when KVM
> point
On Thu, 18 Mar 2021 14:38:53 -0400
Tony Krowiak wrote:
> On 3/17/21 7:17 PM, Halil Pasic wrote:
> > On Wed, 10 Mar 2021 10:05:59 -0500
> > Tony Krowiak wrote:
> >
> >> - ret = vfio_ap_mdev_reset_queues(mdev);
> >> +
On Thu, 18 Mar 2021 13:54:06 -0400
Tony Krowiak wrote:
> > Is it guaranteed that matrix_mdev can't be NULL here? If yes, please
> > remind me of the mechanism that ensures this.
>
> The matrix_mdev is set as drvdata when the mdev is created and
> is only cleared when the mdev is removed.
On Wed, 10 Mar 2021 10:05:59 -0500
Tony Krowiak wrote:
> - ret = vfio_ap_mdev_reset_queues(mdev);
> + matrix_mdev = mdev_get_drvdata(mdev);
Is it guaranteed that matrix_mdev can't be NULL here? If yes, please
remind me of the mechanism that ensures this.
> +
> +
On Thu, 4 Mar 2021 12:43:44 -0500
Tony Krowiak wrote:
> On the other hand, if we don't have ->kvm because something broke,
> then we may be out of luck anyway. There will certainly be no
> way to unregister the GISC; however, it may still be possible
> to unpin the pages if we still have
On Mon, 08 Mar 2021 14:49:42 -0700
Alex Williamson wrote:
> Cleanup disrecommended usage and docs.
>
> Signed-off-by: Alex Williamson
Acked-by: Halil Pasic
On Wed, 3 Mar 2021 11:41:22 -0500
Tony Krowiak wrote:
> > How do you exect userspace to react to this -ENODEV?
>
> The VFIO_DEVICE_RESET ioctl expects a return code.
> The vfio_ap_mdev_reset_queues() function can return -EIO or
> -EBUSY, so I would expect userspace to handle -ENODEV
>
On Wed, 3 Mar 2021 12:10:11 -0500
Tony Krowiak wrote:
> On 3/3/21 10:23 AM, Halil Pasic wrote:
> > On Tue, 2 Mar 2021 15:43:22 -0500
> > Tony Krowiak wrote:
> >
> >> This patch fixes a lockdep splat introduced by commit f21916ec4826
> >> ("s390/
On Tue, 2 Mar 2021 15:43:22 -0500
Tony Krowiak wrote:
> This patch fixes a lockdep splat introduced by commit f21916ec4826
> ("s390/vfio-ap: clean up vfio_ap resources when KVM pointer invalidated").
> The lockdep splat only occurs when starting a Secure Execution guest.
> Crypto virtualization
On Thu, 25 Feb 2021 08:53:50 -0500
Tony Krowiak wrote:
> If we add the proposed flag to indicate when the matrix_mdev->kvm
> pointer is in flux, then we can check that before allowing the functions
> in the list above to proceed.
I'm not against that. Go ahead!
Regards,
Halil
On Thu, 25 Feb 2021 10:25:24 -0500
Tony Krowiak wrote:
> On 2/25/21 8:53 AM, Tony Krowiak wrote:
> >
> >
> > On 2/25/21 6:28 AM, Halil Pasic wrote:
> >> On Wed, 24 Feb 2021 22:28:50 -0500
> >> Tony Krowiak wrote:
> >>
> >>>&g
On Wed, 24 Feb 2021 22:28:50 -0500
Tony Krowiak wrote:
> >> static void vfio_ap_mdev_unset_kvm(struct ap_matrix_mdev *matrix_mdev)
> >> {
> >> - kvm_arch_crypto_clear_masks(matrix_mdev->kvm);
> >> - matrix_mdev->kvm->arch.crypto.pqap_hook = NULL;
> >> -
e lock is definitely
> needed to protect the setting/unsetting of the KVM pointer, it is not
> necessarily critical for setting the masks, so this will not be done under
> protection of the matrix_dev->lock.
With the one little thing I commented on below addressed:
Acked-by: Halil
On Thu, 11 Feb 2021 09:21:26 -0500
Tony Krowiak wrote:
> Yes, it makes sense. I guess I didn't look closely at your
> suggestion when I said it was exactly what I implemented
> after agreeing with Connie. I had a slight difference in
> my implementation:
>
> static void
On Wed, 10 Feb 2021 17:05:48 -0500
Tony Krowiak wrote:
> On 2/10/21 10:32 AM, Halil Pasic wrote:
> > On Wed, 10 Feb 2021 16:24:29 +0100
> > Halil Pasic wrote:
> >
> >>> Maybe you could
> >>> - grab a reference to kvm while holding the
On Wed, 10 Feb 2021 16:24:29 +0100
Halil Pasic wrote:
> > Maybe you could
> > - grab a reference to kvm while holding the lock
> > - call the mask handling functions with that kvm reference
> > - lock again, drop the reference, and do the rest of the processing?
>
On Wed, 10 Feb 2021 11:53:34 +0100
Cornelia Huck wrote:
> On Tue, 9 Feb 2021 14:48:30 -0500
> Tony Krowiak wrote:
>
> > This patch fixes a circular locking dependency in the CI introduced by
> > commit f21916ec4826 ("s390/vfio-ap: clean up vfio_ap resources when KVM
> > pointer invalidated").
On Wed, 3 Feb 2021 18:13:09 -0500
Tony Krowiak wrote:
> On 1/12/21 12:55 PM, Halil Pasic wrote:
> > On Tue, 12 Jan 2021 02:12:51 +0100
> > Halil Pasic wrote:
> >
> >>> @@ -1347,8 +1437,11 @@ void vfio_ap_mdev_remove_queue(struct ap_device
> >>>
On Thu, 21 Jan 2021 09:20:44 +0100
Cornelia Huck wrote:
> On Thu, 21 Jan 2021 08:20:08 +0100
> Halil Pasic wrote:
[..]
> > --- a/drivers/s390/crypto/vfio_ap_private.h
> > +++ b/drivers/s390/crypto/vfio_ap_private.h
> > @@ -88,11 +88,6 @@ struct ap_matrix_mdev {
> >
a bugfix.
Signed-off-by: Tony Krowiak
[pa...@linux.ibm.com: minor rework before merging]
Reviewed-by: Halil Pasic
Signed-off-by: Halil Pasic
Fixes: ec89b55e3bce ("s390: ap: implement PAPQ AQIC interception in kernel")
Cc:
---
Since it turned out disabling the interrupts via
On Thu, 14 Jan 2021 12:54:39 -0500
Tony Krowiak wrote:
> >> /**
> >>* vfio_ap_mdev_verify_no_sharing
> >>*
> >> - * Verifies that the APQNs derived from the cross product of the AP
> >> adapter IDs
> >> - * and AP queue indexes comprising the AP matrix are not configured for
> >>
On Thu, 14 Jan 2021 12:54:39 -0500
Tony Krowiak wrote:
> On 1/11/21 3:40 PM, Halil Pasic wrote:
> > On Tue, 22 Dec 2020 20:15:57 -0500
> > Tony Krowiak wrote:
> >
> >> The current implementation does not allow assignment of an AP adapter or
> >> domain t
On Wed, 13 Jan 2021 19:46:03 -0500
Tony Krowiak wrote:
> On 1/13/21 4:21 PM, Halil Pasic wrote:
> > On Wed, 13 Jan 2021 12:06:28 -0500
> > Tony Krowiak wrote:
> >
> >> On 1/11/21 11:32 AM, Halil Pasic wrote:
> >>> On Tue, 22 Dec 202
On Wed, 13 Jan 2021 16:41:27 -0500
Tony Krowiak wrote:
> On 1/11/21 2:17 PM, Halil Pasic wrote:
> > On Tue, 22 Dec 2020 20:15:56 -0500
> > Tony Krowiak wrote:
> >
> >> Let's create links between each queue device bound to the vfio_ap device
> >> driver a
On Wed, 13 Jan 2021 12:06:28 -0500
Tony Krowiak wrote:
> On 1/11/21 11:32 AM, Halil Pasic wrote:
> > On Tue, 22 Dec 2020 20:15:53 -0500
> > Tony Krowiak wrote:
> >
> >> The queues assigned to a matrix mediated device are currently reset when:
> >>
> &
On Tue, 22 Dec 2020 20:16:05 -0500
Tony Krowiak wrote:
> Implements the driver callback invoked by the AP bus when the AP bus
> scan has completed. Since this callback is invoked after binding the newly
> added devices to their respective device drivers, the vfio_ap driver will
> attempt to hot
On Tue, 22 Dec 2020 20:16:04 -0500
Tony Krowiak wrote:
> The motivation for config change notification is to enable the vfio_ap
> device driver to handle hot plug/unplug of AP queues for a KVM guest as a
> bulk operation. For example, if a new APID is dynamically assigned to the
> host
On Tue, 12 Jan 2021 02:12:51 +0100
Halil Pasic wrote:
> > @@ -1347,8 +1437,11 @@ void vfio_ap_mdev_remove_queue(struct ap_device
> > *apdev)
> > apqi = AP_QID_QUEUE(q->apqn);
> > vfio_ap_mdev_reset_queue(apid, apqi, 1);
> >
> > - if (q-&
te that changes to the apmask and aqmask do not trigger
> these two callbacks since the bus scan function is not invoked by changes
> to those masks.
>
> Signed-off-by: Harald Freudenberger
> Signed-off-by: Tony Krowiak
Reviewed-by: Halil Pasic
[..]
m from the
> vfio_ap device driver.
>
> Signed-off-by: Tony Krowiak
> Reviewed-by: Harald Freudenberger
Reviewed-by: Halil Pasic
On Tue, 12 Jan 2021 09:14:07 -0500
Matthew Rosato wrote:
> On 1/11/21 8:20 PM, Halil Pasic wrote:
> > On Tue, 22 Dec 2020 20:16:02 -0500
> > Tony Krowiak wrote:
> >
> >> Let's implement the callback to indicate when an APQN
> >> is in use by
t; used to lock the matrix device during assignment of adapters and domains
> and the ap_perms_mutex locked by the AP bus when changes are made to the
> sysfs apmask/aqmask attributes.
>
> Consider following scenario (courtesy of Halil Pasic):
> 1) apmask_store() takes ap_perms_mu
mdev that do not reference an AP queue
> + * device bound to the vfio_ap device driver.
> + *
> + * @matrix_mdev: the matrix mdev whose AP configuration is to be filtered
> + * @shadow_apcb: the shadow of the KVM guest's APCB (contains AP
> configuration
> + * for guest)
> + * @filter
iak
> Reviewed-by: Halil Pasic
> ---
> drivers/s390/crypto/vfio_ap_ops.c | 15 +++
> drivers/s390/crypto/vfio_ap_private.h | 2 ++
> 2 files changed, 17 insertions(+)
>
> diff --git a/drivers/s390/crypto/vfio_ap_ops.c
> b/drivers/s390/crypto/vfio_ap_o
and domains that are or will be assigned to the APCB of a guest
> that is or will be using the matrix mdev. For a matrix mdev denoted by
> $uuid, the guest matrix can be displayed as follows:
>
>cat /sys/devices/vfio_ap/matrix/$uuid/guest_matrix
>
> Signed-off-by: Tony Krow
On Tue, 22 Dec 2020 20:15:57 -0500
Tony Krowiak wrote:
> The current implementation does not allow assignment of an AP adapter or
> domain to an mdev device if each APQN resulting from the assignment
> does not reference an AP queue device that is bound to the vfio_ap device
> driver. This patch
* When an adapter or domain is unassigned from a matrix mdev, for each
> APQN unassigned that references a queue device bound to the vfio_ap
> device driver, the structures representing the queue device and the
> matrix mdev will be unlinked.
>
> Signed-off-by: Tony Kr
d not work and
we are giving up. So the irqs are potentially still enabled.
Without this patch we try to disable the interrupts using AQIC, and
do the cleanup after that.
I'm aware, the comment says we should not take the default branch,
but if that's really the case we should IMHO log an
On Wed, 6 Jan 2021 10:16:24 -0500
Tony Krowiak wrote:
> Ping
>
pong
Will try have a look these days...
eceive
> notification that the KVM pointer has been set to NULL, the vfio_ap device
> driver should reverse the actions taken when the KVM pointer was set.
>
> Fixes: 258287c994de ("s390: vfio-ap: implement mediated device open callback")
> Cc: sta...@vger.kernel.org
&g
On Tue, 22 Dec 2020 16:57:06 +0100
Cornelia Huck wrote:
> On Tue, 22 Dec 2020 10:37:01 -0500
> Tony Krowiak wrote:
>
> > On 12/21/20 11:05 PM, Halil Pasic wrote:
> > > On Mon, 21 Dec 2020 13:56:25 -0500
> > > Tony Krowiak wrote:
>
> > >>
eceive
> notification that the KVM pointer has been set to NULL, the vfio_ap device
> driver should reverse the actions taken when the KVM pointer was set.
>
> Fixes: 258287c994de ("s390: vfio-ap: implement mediated device open callback")
> Cc: sta...@vger.kernel.org
&g
On Wed, 16 Dec 2020 10:58:48 +0100
Christian Borntraeger wrote:
> On 16.12.20 02:21, Halil Pasic wrote:
> > On Tue, 15 Dec 2020 19:10:20 +0100
> > Christian Borntraeger wrote:
> >
> >>
> >>
> >> On 15.12.20 11:57, Halil Pasic wrote:
> >&g
On Wed, 16 Dec 2020 15:14:47 -0500
Tony Krowiak wrote:
>
>
> On 11/28/20 8:17 PM, Halil Pasic wrote:
> > On Tue, 24 Nov 2020 16:40:10 -0500
> > Tony Krowiak wrote:
> >
> >> The current implementation does not allow assignment of an AP adapter or
> &
On Wed, 16 Dec 2020 17:05:24 +0100
Christian Borntraeger wrote:
>
>
> On 16.12.20 10:58, Christian Borntraeger wrote:
> > On 16.12.20 02:21, Halil Pasic wrote:
> >> On Tue, 15 Dec 2020 19:10:20 +0100
> >> Christian Borntraeger wrote:
> >>
> >>
On Tue, 15 Dec 2020 19:10:20 +0100
Christian Borntraeger wrote:
>
>
> On 15.12.20 11:57, Halil Pasic wrote:
> > On Mon, 14 Dec 2020 11:56:17 -0500
> > Tony Krowiak wrote:
> >
> >> The vfio_ap device driver registers a group notifier with VFIO when the
>
On Mon, 14 Dec 2020 11:56:17 -0500
Tony Krowiak wrote:
> The vfio_ap device driver registers a group notifier with VFIO when the
> file descriptor for a VFIO mediated device for a KVM guest is opened to
> receive notification that the KVM pointer is set (VFIO_GROUP_NOTIFY_SET_KVM
> event). When
On Fri, 11 Dec 2020 16:08:53 -0500
Tony Krowiak wrote:
> >>> +static void vfio_ap_mdev_put_kvm(struct ap_matrix_mdev *matrix_mdev)
> >>> +{
> >>> + if (matrix_mdev->kvm) {
> >>> + kvm_arch_crypto_clear_masks(matrix_mdev->kvm);
> >>> + matrix_mdev->kvm->arch.crypto.pqap_hook =
On Fri, 11 Dec 2020 15:52:55 -0500
Tony Krowiak wrote:
>
>
> On 12/7/20 7:01 PM, Halil Pasic wrote:
> > On Mon, 7 Dec 2020 13:50:36 -0500
> > Tony Krowiak wrote:
> >
> >> On 12/4/20 2:05 PM, Halil Pasic wrote:
> >>> On Fri, 4 D
On Mon, 7 Dec 2020 14:05:55 -0500
Tony Krowiak wrote:
>
>
> On 12/2/20 6:41 PM, Tony Krowiak wrote:
> > The vfio_ap device driver registers a group notifier with VFIO when the
> > file descriptor for a VFIO mediated device for a KVM guest is opened to
> > receive notification that the KVM
On Mon, 7 Dec 2020 13:50:36 -0500
Tony Krowiak wrote:
> On 12/4/20 2:05 PM, Halil Pasic wrote:
> > On Fri, 4 Dec 2020 09:43:59 -0500
> > Tony Krowiak wrote:
> >
> >>>> +{
> >>>> +if (matrix_mdev->kvm) {
> >>>> +
On Fri, 4 Dec 2020 11:48:24 -0500
Tony Krowiak wrote:
> On 12/3/20 12:55 PM, Halil Pasic wrote:
> > On Wed, 2 Dec 2020 18:41:01 -0500
> > Tony Krowiak wrote:
> >
> >> The vfio_ap device driver registers a group notifier with VFIO when the
> >> fil
On Fri, 4 Dec 2020 14:46:30 -0500
Tony Krowiak wrote:
> On 12/4/20 2:05 PM, Halil Pasic wrote:
> > On Fri, 4 Dec 2020 09:43:59 -0500
> > Tony Krowiak wrote:
> >
> >>>> +{
> >>>> +if (matrix_mdev->kvm) {
> >>>> +
On Fri, 4 Dec 2020 09:43:59 -0500
Tony Krowiak wrote:
> >> +{
> >> + if (matrix_mdev->kvm) {
> >> + (matrix_mdev->kvm);
> >> + matrix_mdev->kvm->arch.crypto.pqap_hook = NULL;
> > Is a plain assignment to arch.crypto.pqap_hook apropriate, or do we need
> > to take more care?
On Wed, 2 Dec 2020 18:41:01 -0500
Tony Krowiak wrote:
> The vfio_ap device driver registers a group notifier with VFIO when the
> file descriptor for a VFIO mediated device for a KVM guest is opened to
> receive notification that the KVM pointer is set (VFIO_GROUP_NOTIFY_SET_KVM
> event). When
On Thu, 3 Dec 2020 11:19:07 +0100
Cornelia Huck wrote:
> > @@ -1095,7 +1106,7 @@ static int vfio_ap_mdev_group_notifier(struct
> > notifier_block *nb,
> > matrix_mdev = container_of(nb, struct ap_matrix_mdev, group_notifier);
> >
> > if (!data) {
> > - matrix_mdev->kvm =
On Tue, 1 Dec 2020 17:12:56 -0500
Tony Krowiak wrote:
> On 12/1/20 12:56 PM, Halil Pasic wrote:
> > On Tue, 1 Dec 2020 00:32:27 +0100
> > Halil Pasic wrote:
> >
> >>>
> >>> On 11/28/20 8:52 PM, Halil Pasic wrote:
> >>
On Tue, 1 Dec 2020 00:32:27 +0100
Halil Pasic 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 KV
On Mon, 30 Nov 2020 19:18:30 -0500
Tony Krowiak wrote:
> +static bool vfio_ap_assign_apid_to_apcb(struct ap_matrix_mdev
> *matrix_mdev,
> +unsigned long apid)
> +{
> +unsigned long apqi, apqn;
> +unsigned long
On Mon, 30 Nov 2020 14:36:10 -0500
Tony Krowiak 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
On Mon, 30 Nov 2020 09:30:33 +0100
Niklas Schnelle wrote:
> I'm not really familiar, with it but I think this is closely related
> to what I asked Bernd Nerz. I fear that if CPUs go away we might already
> be in trouble at the firmware/hardware/platform level because the CPU Address
> is
>
On Tue, 24 Nov 2020 16:40:11 -0500
Tony Krowiak wrote:
> Let's hot plug/unplug adapters, domains and control domains assigned to or
> unassigned from an AP matrix mdev device while it is in use by a guest per
> the following rules:
>
> * Assign an adapter to mdev's matrix:
>
> The adapter
On Tue, 24 Nov 2020 16:40:10 -0500
Tony Krowiak wrote:
> The current implementation does not allow assignment of an AP adapter or
> domain to an mdev device if each APQN resulting from the assignment
> does not reference an AP queue device that is bound to the vfio_ap device
> driver. This patch
On Tue, 24 Nov 2020 16:40:09 -0500
Tony Krowiak wrote:
> The APCB is a control block containing the masks that specify the adapters,
> domains and control domains to which a KVM guest is granted access. When
> the vfio_ap device driver is notified that the KVM pointer has been set,
> the guest's
On Tue, 24 Nov 2020 16:40:08 -0500
Tony Krowiak wrote:
> The matrix of adapters and domains configured in a guest's APCB may
> differ from the matrix of adapters and domains assigned to the matrix mdev,
> so this patch introduces a sysfs attribute to display the matrix of
> adapters and domains
iak
> Reviewed-by: Halil Pasic
Still LGTM
On Fri, 27 Nov 2020 11:08:10 +0100
Niklas Schnelle wrote:
>
>
> On 11/27/20 9:56 AM, Halil Pasic wrote:
> > On Thu, 26 Nov 2020 18:00:37 +0100
> > Alexander Gordeev wrote:
> >
> >> The directed MSIs are delivered to CPUs whose address is
> >> writ
cpu = cpumask_first(>affinity->mask);
> + else
> + cpu = 0;
> + cpu_addr = smp_cpu_get_cpu_address(cpu);
> +
I thin style wise, I would prefer keeping the ternary operator instead
of rewriting it as an if-th
t; used to lock the matrix device during assignment of adapters and domains
> and the ap_perms_mutex locked by the AP bus when changes are made to the
> sysfs apmask/aqmask attributes.
>
> Consider following scenario (courtesy of Halil Pasic):
> 1) apmask_store() takes ap_perms_mu
On Tue, 24 Nov 2020 16:40:04 -0500
Tony Krowiak wrote:
> Let's create links between each queue device bound to the vfio_ap device
> driver and the matrix mdev to which the queue is assigned. The idea is to
> facilitate efficient retrieval of the objects representing the queue
> devices and
On Tue, 24 Nov 2020 16:40:04 -0500
Tony Krowiak wrote:
> @@ -1155,6 +1243,11 @@ static int vfio_ap_mdev_reset_queues(struct
> mdev_device *mdev)
>matrix_mdev->matrix.apm_max + 1) {
> for_each_set_bit_inv(apqi, matrix_mdev->matrix.aqm,
>
ately after the reset of a queue, a call is made to disable
> interrupts for the queue. This is entirely unnecessary because the reset of
> a queue disables interrupts, so this will be removed.
>
> Signed-off-by: Tony Krowiak
Reviewed-by: Halil Pasic
As I said previously, I would prefer
On Tue, 24 Nov 2020 16:40:02 -0500
Tony Krowiak wrote:
A nit: for all other patches the title prefix is s390/vfio-ap, here you
have 390/vfio-ap.
On Tue, 24 Nov 2020 16:40:01 -0500
Tony Krowiak wrote:
> Decrement the reference count to KVM when notified that KVM pointer is
> invalidated via the vfio group notifier.
Can you please explain more thoroughly. Is this a bug you found? If
yes do we need to backport it (cc stabe, fixes tag)?
ate.h header file defining the public interfaces for the
> vfio_ap device driver.
>
> Signed-off-by: Tony Krowiak
Reviewed-by: Halil Pasic
On Fri, 13 Nov 2020 16:30:31 -0500
Tony Krowiak wrote:
> We will be using the mutex_trylock() function in our sysfs
> assignment
> interfaces which make the call to the AP bus to check permissions (which
> also
> locks ap_perms). If the mutex_trylock() fails, we return from the assignment
>
On Fri, 13 Nov 2020 12:14:22 -0500
Tony Krowiak wrote:
[..]
> >> }
> >>
> >> +#define MDEV_SHARING_ERR "Userspace may not re-assign queue %02lx.%04lx "
> >> \
> >> + "already assigned to %s"
> >> +
> >> +static void vfio_ap_mdev_log_sharing_err(const char *mdev_name,
> >>
On Fri, 13 Nov 2020 12:27:32 -0500
Tony Krowiak wrote:
>
>
> On 10/28/20 4:17 AM, Halil Pasic wrote:
> > On Thu, 22 Oct 2020 13:12:02 -0400
> > Tony Krowiak wrote:
> >
> >> +static ssize_t guest_matrix_show(struct device *dev,
> >> +
On Wed, 4 Nov 2020 16:20:26 -0500
Tony Krowiak wrote:
> > But I'm sure the code is suggesting it can, because
> > vfio_ap_mdev_filter_guest_matrix() has a third parameter called filter_apid,
> > which governs whether the apm or the aqm bit should be removed. And
> >
On Tue, 3 Nov 2020 17:49:21 -0500
Tony Krowiak wrote:
> > We do this to show the no queues but bits set output in show? We could
> > get rid of some code if we were to not z
Managed to delete "eroize" fro "zeroize"
>
> I'm not sure what you are saying/asking here. The reason for this
> is
On Tue, 3 Nov 2020 17:49:21 -0500
Tony Krowiak wrote:
> >>
> >> +void vfio_ap_mdev_hot_unplug_queue(struct vfio_ap_queue *q)
> >> +{
> >> + unsigned long apid = AP_QID_CARD(q->apqn);
> >> +
> >> + if ((q->matrix_mdev == NULL) || !vfio_ap_mdev_has_crycb(q->matrix_mdev))
> >> +
On Fri, 30 Oct 2020 16:37:04 -0400
Tony Krowiak wrote:
> On 10/30/20 1:42 PM, Halil Pasic wrote:
> > On Thu, 29 Oct 2020 19:29:35 -0400
> > Tony Krowiak wrote:
> >
> >>>> @@ -1177,7 +1166,10 @@ static int vfio_ap_mdev_reset_que
On Thu, 29 Oct 2020 19:29:35 -0400
Tony Krowiak wrote:
> >> +void vfio_ap_mdev_remove_queue(struct ap_device *apdev)
> >> +{
> >> + struct vfio_ap_queue *q;
> >> + struct ap_queue *queue;
> >> + int apid, apqi;
> >> +
> >> + queue = to_ap_queue(>device);
> > What is the benefit of
On Thu, 29 Oct 2020 19:29:35 -0400
Tony Krowiak wrote:
> >> @@ -1177,7 +1166,10 @@ static int vfio_ap_mdev_reset_queues(struct
> >> mdev_device *mdev)
> >> */
> >>if (ret)
> >>rc = ret;
> >> -
On Thu, 29 Oct 2020 19:29:35 -0400
Tony Krowiak wrote:
> >> @@ -1177,7 +1166,10 @@ static int vfio_ap_mdev_reset_queues(struct
> >> mdev_device *mdev)
> >> */
> >>if (ret)
> >>rc = ret;
> >> -
On Thu, 29 Oct 2020 19:29:35 -0400
Tony Krowiak wrote:
> On 10/27/20 2:48 AM, Halil Pasic wrote:
> > On Thu, 22 Oct 2020 13:11:56 -0400
> > Tony Krowiak wrote:
> >
> >> The queues assigned to a matrix mediated device are currently reset when:
> >>
> &
On Thu, 22 Oct 2020 13:12:02 -0400
Tony Krowiak wrote:
> +static ssize_t guest_matrix_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + ssize_t nchars;
> + struct mdev_device *mdev = mdev_from_dev(dev);
> + struct
On Thu, 22 Oct 2020 13:12:03 -0400
Tony Krowiak wrote:
> In response to the probe or remove of a queue device, if a KVM guest is
> using the matrix mdev to which the APQN of the queue device is assigned,
> the vfio_ap device driver must respond accordingly. In an ideal world, the
> queue device
memcpy(_mdev->shadow_apcb, _mdev->matrix,
> +sizeof(matrix_mdev->shadow_apcb));
> + vfio_ap_mdev_commit_shadow_apcb(matrix_mdev);
>
> return NOTIFY_OK;
> }
> @@ -1329,6 +1342,7 @@ static void vfio_ap_mdev_release(struct mdev_device
> *mdev
On Thu, 22 Oct 2020 13:12:04 -0400
Tony Krowiak wrote:
> +static int vfio_ap_mdev_validate_masks(struct ap_matrix_mdev *matrix_mdev,
> +unsigned long *mdev_apm,
> +unsigned long *mdev_aqm)
> +{
> + if
On Thu, 22 Oct 2020 13:12:00 -0400
Tony Krowiak wrote:
> Let's implement the callback to indicate when an APQN
> is in use by the vfio_ap device driver. The callback is
> invoked whenever a change to the apmask or aqmask would
> result in one or more queue devices being removed from the driver.
e_probe() and I don't quite understand some
usages of in zcrypt_api.c My feeling is that the extra pressure on that
lock should not be a problem, except if in_use() were to not return
because of some deadlock.
With all that said if Harald is fine with it, so am I.
Acked-by: Halil Pasic
>
&g
On Thu, 22 Oct 2020 13:11:58 -0400
Tony Krowiak wrote:
> Let's create links between each queue device bound to the vfio_ap device
> driver and the matrix mdev to which the queue is assigned. The idea is to
> facilitate efficient retrieval of the objects representing the queue
> devices and
ap_get_qdev() function retrieves the queue device from a
> hashtable keyed by APQN. This is much more efficient than looping over
> the list of devices attached to the AP bus by several orders of
> magnitude.
>
> Signed-off-by: Tony Krowiak
Reviewed-by: Halil Pasic
> ---
>
On Thu, 22 Oct 2020 13:11:56 -0400
Tony Krowiak wrote:
> The queues assigned to a matrix mediated device are currently reset when:
>
> * The VFIO_DEVICE_RESET ioctl is invoked
> * The mdev fd is closed by userspace (QEMU)
> * The mdev is removed from sysfs.
What about the situation when
On Tue, 20 Oct 2020 09:18:48 +0300
"Kirill A. Shutemov" wrote:
> VirtIO for KVM is a primary way to provide IO. All memory that used for
> communication with the host has to be marked as shared.
>
> The easiest way to archive that is to use DMA API that already knows how
> to deal with shared
1 - 100 of 391 matches
Mail list logo
