[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210714130208.1eb5c677.alex.williamson@redhat.com>
Date: Wed, 14 Jul 2021 13:02:08 -0600
From: Alex Williamson <alex.williamson@...hat.com>
To: Christian Borntraeger <borntraeger@...ibm.com>
Cc: Tony Krowiak <akrowiak@...ux.ibm.com>,
Jason Gunthorpe <jgg@...dia.com>,
Halil Pasic <pasic@...ux.ibm.com>, linux-s390@...r.kernel.org,
linux-kernel@...r.kernel.org, cohuck@...hat.com,
pasic@...ux.vnet.ibm.com, jjherne@...ux.ibm.com,
kwankhede@...dia.com, frankja@...ux.ibm.com, david@...hat.com,
imbrenda@...ux.ibm.com, hca@...ux.ibm.com
Subject: Re: [PATCH] s390/vfio-ap: do not open code locks for
VFIO_GROUP_NOTIFY_SET_KVM notification
On Wed, 14 Jul 2021 19:56:42 +0200
Christian Borntraeger <borntraeger@...ibm.com> wrote:
> On 14.07.21 15:25, Tony Krowiak wrote:
> >
> >> This patch shows it works as a rwsem - look at what had to be changed
> >> to make it so and you will find some clue to where the problems are in
> >> kvm_busy version.
> >>
> >> In any event, I don't care anymore - please just get this merged, to
> >> AlexW's tree so I don't have conflicts with the rest of the ap changes
> >> for VFIO I've got queued up.
> >
> > Christian, can you merge this with AlexW's tree? Halil suggested
> > the 'fixes' and 'cc stable' tags ought to be removed, do I need
> > to post another version or can you take those out when merging?
>
> Normally this would go via the KVM/s390 or s390 tree (as Alex did
> not want to handle s390 vfio devices).
>
> Alex, as Jason is waiting for this to be in your tree could you take
> this patch via your tree ?(please remove cc stable and Fixes for now
> I want this to settle a bit).
>
> To carry this patch in your tree with my kvm/s390 and s390 maintainer hat
> Acked-by: Christian Borntraeger <borntraeger@...ibm.com>
Is this intended for v5.14 or v5.15? I don't have a v5.15 next branch
yet, so if this were to get into v5.14 before I create that, it'd be
there for Jason as well. Posting a branch that we both merge into our
linux-next branches would be another option. I can take it either way,
just trying to understand what we're wanting to achieve. Thanks,
Alex
Powered by blists - more mailing lists