On Wed, 16 Apr 2025 15:49:40 +0200
Amit Shah wrote:
> On Sat, 2025-03-22 at 01:29 +0100, Halil Pasic wrote:
> > As per virtio spec the fields cols and rows are specified as little
> > endian. Although there is no legacy interface requirement that would
> > state that col
On Mon, 07 Apr 2025 15:28:13 +0200
Cornelia Huck wrote:
> > Staring at the cross-vmm, including the adding+removing of features and
> > queues that are not in the spec, I am wondering if (in a world with
> > fixed virtqueues)
> >
> > 1) Feature bits must be reserved before used.
> >
> > 2) Queu
On Mon, 7 Apr 2025 04:34:29 -0400
"Michael S. Tsirkin" wrote:
> On Mon, Apr 07, 2025 at 10:17:10AM +0200, David Hildenbrand wrote:
> > On 07.04.25 09:52, Michael S. Tsirkin wrote:
> > > On Fri, Apr 04, 2025 at 05:39:10PM +0200, Halil Pasic wrote:
> > > &
On Fri, 4 Apr 2025 01:33:28 -0400
"Michael S. Tsirkin" wrote:
> >
> > I think, a consequence of this design is that all queues need to be
> > created and allocated at initialization time.
>
> Why? after feature negotiation.
What I mean is, with this change having queues that exist but are no
e merit of the kernel interface
virtio_find_vqs() supporting "holes" is quite questionable. Now we need
it because the drivers within the Linux kernel still think of the queues
in terms of the current spec, i.e. they try to have the "holes" as
mandated by the spec, and the duty of
On Fri, 4 Apr 2025 16:17:14 +0200
David Hildenbrand wrote:
> > It is offered. And this is precisely why I'm so keen on having a
> > precise wording here.
>
> Yes, me too. The current phrasing in the spec is not clear.
>
> Linux similarly checks
> virtio_has_feature()->virtio_check_driver_off
On Fri, 4 Apr 2025 12:55:09 +0200
David Hildenbrand wrote:
> For virito-balloon, we should probably do the following:
>
> From 38e340c2bb53c2a7cc7c675f5dfdd44ecf7701d9 Mon Sep 17 00:00:00 2001
> From: David Hildenbrand
> Date: Fri, 4 Apr 2025 12:53:16 +0200
> Subject: [PATCH] virtio-balloon: F
On Fri, 4 Apr 2025 15:48:49 +0200
David Hildenbrand wrote:
> > Sounds good to me! But I'm still a little confused by the "holes".
> > What confuses me is that i can think of at least 2 distinct types of
> > "holes": 1) Holes that can be filled later. The queue conceptually
> > exists, but there i
On Thu, 3 Apr 2025 10:35:33 -0400
"Michael S. Tsirkin" wrote:
> On Thu, Apr 03, 2025 at 04:18:36PM +0200, Halil Pasic wrote:
> > On Wed, 2 Apr 2025 22:36:21 +0200
[..]
> >
> > 5.5.2 Virtqueues
> >
> > 0
> > inflateq
> > 1
> >
On Wed, 2 Apr 2025 22:36:21 +0200
David Hildenbrand wrote:
> If we finds a vq without a name in our input array in
> virtio_ccw_find_vqs(), we treat it as "non-existing" and set the vq pointer
> to NULL; we will not call virtio_ccw_setup_vq() to allocate/setup a vq.
>
> Consequently, we create
On Sat, 22 Mar 2025 01:29:54 +0100
Halil Pasic wrote:
> As per virtio spec the fields cols and rows are specified as little
> endian.
[..]
@Amit: Any feedback?
>
> Fixes: 8345adbf96fc1 ("virtio: console: Accept console size along with resize
> control message")
>
On Thu, 20 Mar 2025 15:09:57 +0100
Halil Pasic wrote:
> > I already implemented it in my patch v2 (just waiting for Amit to
> > confirm the new commit message). But if you want to split it you can
> > create a seperate patch for it as well (I don't really mind either
&g
nel
> implementation assums native endianness (which results in mangled
> values on big endian architectures)(a seperate patch by Halil Pasic
> will deal with that issue) and swaps the ordering of columns and rows.
I would simply omit the reference to the other patch. I understand that
yo
ssage")
Signed-off-by: Halil Pasic
Cc: sta...@vger.kernel.org # v2.6.35+
---
@Michael: I think it would be nice to add a clarification on the byte
order to be used for cols and rows when the legacy interface is used to
the spec, regardless of what we decide the right byte order is. If
it is native e
On Thu, 20 Mar 2025 12:53:43 +0100
Maximilian Immanuel Brandtner wrote:
> On Thu, 2025-03-20 at 11:41 +0100, Halil Pasic wrote:
> > On Thu, 20 Mar 2025 08:12:23 +0100
> > Maximilian Immanuel Brandtner wrote:
> >
> > > > Another thing I noticed during l
On Thu, 20 Mar 2025 08:12:23 +0100
Maximilian Immanuel Brandtner wrote:
> > Another thing I noticed during looking at this. AFAICT Linux does not
> > seem to handle endiannes here. And AFAIU the message is supposed to
> > hold
> > le16 that is little endian u16! Maximilian, is this in your opinio
On Wed, 19 Mar 2025 11:00:06 -0400
"Michael S. Tsirkin" wrote:
> > > I was mistaken in my earlier reply - I had missed this
> > > virtio_console_resize definition in the spec. So indeed there's a
> > > discrepancy in Linux kernel and the spec's ordering for the control
> > > message.
> > >
> >
On Tue, 08 Oct 2024 10:47:48 +0200
"Marc Hartmayer" wrote:
> > Closes: https://bugzilla.linux.ibm.com/show_bug.cgi?id=209131
>
> I guess, this line can be removed as it’s internal only.
checkpatch.pl complains about the Reported-by if I do.
It does not complain about
Closes: N/A
but if I re
mmon virtio DMA infrastructure is such that most of the DMA stuff
hinges on the virtio parent device, which is a CCW device.
So lets set up the dma_parms pointer for the CCW parent device and hope
for the best!
Signed-off-by: Halil Pasic
Fixes: 334304ac2bac ("dma-mapping: don&
vqi->name, vqi->ctx, ccw);
> if (IS_ERR(vqs[i])) {
> ret = PTR_ERR(vqs[i]);
Acked-by: Halil Pasic #s390
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/virt
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 a
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
[ 4422.5170
m wait queue. 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
> poi
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);
> >> + matrix_mde
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. Likew
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 q->saved
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
> similarl
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;
> >> - vfio_ap_mdev_reset_queues(matrix_mde
le the 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: H
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 vfio_ap_mdev_unset_kvm(st
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 lock
>
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 PQAP/A
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
> >> anot
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
> >> dri
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 p
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 configurat
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-&
.
>
> Please note 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
[..]
n unbind them 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 b
gt;lock
> 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 a
p_mdev_refresh_apcb
> + *
> + * Filter APQNs assigned to the matrix 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
Tony Krowiak
> 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
pters 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
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
t;
>* 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-b
Do we really want the unpin here? I mean the reset did 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
On Wed, 6 Jan 2021 10:16:24 -0500
Tony Krowiak wrote:
> Ping
>
pong
Will try have a look these days...
to receive
> 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
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:
>
> > >>
to receive
> 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
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 t
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 = NULL
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 point
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
> >> file desc
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 t
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 = NULL
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 t
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 t
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
> "prog
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 wil
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 t
Tony Krowiak
> 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
ting it as an if-then-else, i.e.:
cpu_addr = smp_cpu_get_cpu_address(msi->affinity ?
cpumask_first(&msi->affinity->mask) : 0);
but either way:
Reviewed-by: Halil Pasic
> msg.addres
gt;lock
> 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 a
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 matrix
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,
>
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)?
It
_private.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
> fun
1 - 100 of 329 matches
Mail list logo
