fio_ccw_chp.c | 2 +-
> drivers/s390/cio/vfio_ccw_drv.c | 4 ++--
> drivers/s390/cio/vfio_ccw_ops.c | 6 +++---
> drivers/s390/crypto/vfio_ap_ops.c | 2 +-
Acked-by: Eric Farman # s390
With the "mess" sorted out, we should be able to inline the
vfio_free_device call introduced by commit cb9ff3f3b84c
("vfio: Add helpers for unifying vfio_device life cycle")
and remove them from driver release callbacks.
Signed-off-by: Eric Farman
Reviewed-by: Jason Gunthorpe
separation of these structs will follow.
Signed-off-by: Eric Farman
Reviewed-by: Matthew Rosato
---
drivers/s390/cio/vfio_ccw_drv.c | 98 +++--
drivers/s390/cio/vfio_ccw_ops.c | 8 ++-
drivers/s390/cio/vfio_ccw_private.h | 20 --
3 files changed, 101 insertions
Now that we have a reasonable separation of structs that follow
the subchannel and mdev lifecycles, there's no reason we can't
call the official vfio_alloc_device routine for our private data,
and behave like everyone else.
Signed-off-by: Eric Farman
Reviewed-by: Kevin Tian
Acke
Now that the mdev parent data is split out into its own struct,
it is safe to move the remaining private data to follow the
mdev probe/remove lifecycle. The mdev parent data will remain
where it is, and follow the subchannel and the css driver
interfaces.
Signed-off-by: Eric Farman
Reviewed-by
These places all rely on the ability to jump from a private
struct back to the subchannel struct. Rather than keeping a
copy in our back pocket, let's use the relationship provided
by the vfio_device embedded within the private.
Signed-off-by: Eric Farman
Reviewed-by: Matthew R
There's enough separation between the parent and private structs now,
that it is fine to remove the release completion hack.
Signed-off-by: Eric Farman
Reviewed-by: Kevin Tian
Reviewed-by: Matthew Rosato
---
drivers/s390/cio/vfio_ccw_ops.c | 14 +-
drivers/s39
equire distinct initialization over to that routine.
With that done, the vfio_ccw_alloc_private routine only does a
kzalloc, so fold it inline.
Signed-off-by: Eric Farman
Reviewed-by: Matthew Rosato
---
drivers/s390/cio/vfio_ccw_drv.c | 74 -
drivers/s390/cio/vfio_ccw
om/
v1: https://lore.kernel.org/kvm/20221019162135.798901-1-far...@linux.ibm.com/
Eric Farman (7):
vfio/ccw: create a parent struct
vfio/ccw: remove private->sch
vfio/ccw: move private initialization to callback
vfio/ccw: move private to mdev lifecycle
vfio/ccw: remove
On Thu, 2022-11-03 at 19:22 -0400, Matthew Rosato wrote:
> On 11/2/22 11:01 AM, Eric Farman wrote:
> > Now that the mdev parent data is split out into its own struct,
> > it is safe to move the remaining private data to follow the
> > mdev probe/remove lifecycle. The mdev pa
On Thu, 2022-11-03 at 19:43 -0400, Matthew Rosato wrote:
> On 11/3/22 5:56 PM, Alex Williamson wrote:
> > On Wed, 2 Nov 2022 16:01:45 +0100
> > Eric Farman wrote:
> >
> > > Hi all,
> > >
> > > Here is an update to the vfio-ccw lifecycle changes
On Wed, 2022-11-02 at 16:01 +0100, Eric Farman wrote:
> Move the stuff associated with the mdev parent (and thus the
> subchannel struct) into its own struct, and leave the rest in
> the existing private structure.
>
> The subchannel will point to the parent, and the parent will
!)
- Patch 6:
[JG] Make vfio_init_device static
[KT] Added r-b (Thank you!)
- Patch 7:
[JG, KT] Added r-b (Thank you!)
v1: https://lore.kernel.org/kvm/20221019162135.798901-1-far...@linux.ibm.com/
Eric Farman (7):
vfio/ccw: create a parent struct
vfio/ccw: remove private->sch
Now that we have a reasonable separation of structs that follow
the subchannel and mdev lifecycles, there's no reason we can't
call the official vfio_alloc_device routine for our private data,
and behave like everyone else.
Signed-off-by: Eric Farman
Reviewed-by: Kevin Tian
---
dr
There's enough separation between the parent and private structs now,
that it is fine to remove the release completion hack.
Signed-off-by: Eric Farman
Reviewed-by: Kevin Tian
---
drivers/s390/cio/vfio_ccw_ops.c | 14 +-
drivers/s390/cio/vfio_ccw_private.h | 3 ---
2
Now that the mdev parent data is split out into its own struct,
it is safe to move the remaining private data to follow the
mdev probe/remove lifecycle. The mdev parent data will remain
where it is, and follow the subchannel and the css driver
interfaces.
Signed-off-by: Eric Farman
---
drivers
With the "mess" sorted out, we should be able to inline the
vfio_free_device call introduced by commit cb9ff3f3b84c
("vfio: Add helpers for unifying vfio_device life cycle")
and remove them from driver release callbacks.
Signed-off-by: Eric Farman
Reviewed-by: Jason Gunthorpe
separation of these structs will follow.
Signed-off-by: Eric Farman
---
drivers/s390/cio/vfio_ccw_drv.c | 96 -
drivers/s390/cio/vfio_ccw_ops.c | 8 ++-
drivers/s390/cio/vfio_ccw_private.h | 20 --
3 files changed, 100 insertions(+), 24 deletions(-)
diff --git a
equire distinct initialization over to that routine.
With that done, the vfio_ccw_alloc_private routine only does a
kzalloc, so fold it inline.
Signed-off-by: Eric Farman
Reviewed-by: Matthew Rosato
---
drivers/s390/cio/vfio_ccw_drv.c | 70 +++--
drivers/s390/cio/vfio_ccw
These places all rely on the ability to jump from a private
struct back to the subchannel struct. Rather than keeping a
copy in our back pocket, let's use the relationship provided
by the vfio_device embedded within the private.
Signed-off-by: Eric Farman
Reviewed-by: Matthew R
On Tue, 2022-11-01 at 09:08 +, Tian, Kevin wrote:
> > From: Eric Farman
> > Sent: Thursday, October 20, 2022 12:22 AM
> >
> > @@ -101,15 +101,20 @@ static int vfio_ccw_mdev_probe(struct
> > mdev_device *mdev)
> > {
> > struct subcha
On Fri, 2022-10-28 at 14:52 -0400, Matthew Rosato wrote:
> On 10/19/22 12:21 PM, Eric Farman wrote:
> > There's already a device initialization callback that is
> > used to initialize the release completion workaround.
>
> As discussed off-list, maybe clarify what callb
On Fri, 2022-10-28 at 12:51 -0400, Matthew Rosato wrote:
> On 10/19/22 12:21 PM, Eric Farman wrote:
> > Move the stuff associated with the mdev parent (and thus the
> > subchannel struct) into its own struct, and leave the rest in
> > the existing private structure.
> &g
On Wed, 2022-10-19 at 18:21 +0200, Eric Farman wrote:
> Move the stuff associated with the mdev parent (and thus the
> subchannel struct) into its own struct, and leave the rest in
> the existing private structure.
>
> The subchannel will point to the parent, and the parent will
On Wed, 2022-10-19 at 14:15 -0300, Jason Gunthorpe wrote:
> On Wed, Oct 19, 2022 at 06:21:34PM +0200, Eric Farman wrote:
>
> > /*
> > * Initialize a vfio_device so it can be registered to vfio core.
> > - *
> > - * Only vfio-ccw driver should call thi
There's already a device initialization callback that is
used to initialize the release completion workaround.
Move the other elements of the vfio_ccw_private struct that
require distinct initialization over to that routine.
Signed-off-by: Eric Farman
---
drivers/s390/cio/vfio_ccw_
rnel.org/kvm/0-v3-57c1502c62fd+2190-ccw_mdev_...@nvidia.com/
[2] https://lore.kernel.org/kvm/20220602171948.2790690-1-far...@linux.ibm.com/
[3] https://lore.kernel.org/kvm/20220923092652.100656-1-...@lst.de/
[4] https://lore.kernel.org/kvm/20220921104401.38898-1-kevin.t...@intel.com/
Eric Farman (7):
Now that the mdev parent data is split out into its own struct,
it is safe to move the remaining private data to follow the
mdev probe/remove lifecycle. The mdev parent data will remain
where it is, and follow the subchannel and the css driver
interfaces.
Signed-off-by: Eric Farman
---
drivers
Now that we have a reasonable separation of structs that follow
the subchannel and mdev lifecycles, there's no reason we can't
call the official vfio_alloc_device routine for our private data,
and behave like everyone else.
Signed-off-by: Eric Farman
---
drivers/s390/cio/vfio_ccw_drv.
With the "mess" sorted out, we should be able to inline the
vfio_free_device call introduced by commit cb9ff3f3b84c
("vfio: Add helpers for unifying vfio_device life cycle")
and remove them from driver release callbacks.
Signed-off-by: Eric Farman
---
drivers/gpu/drm/i915/g
There's enough separation between the parent and private structs now,
that it is fine to remove the release completion hack.
Signed-off-by: Eric Farman
---
drivers/s390/cio/vfio_ccw_ops.c | 14 +-
drivers/s390/cio/vfio_ccw_private.h | 3 ---
2 files changed, 1 insertion(+
separation of these structs will follow.
Signed-off-by: Eric Farman
---
drivers/s390/cio/vfio_ccw_drv.c | 104
drivers/s390/cio/vfio_ccw_ops.c | 9 ++-
drivers/s390/cio/vfio_ccw_parent.h | 28
drivers/s390/cio/vfio_ccw_private.h | 5 --
4 files changed
These places all rely on the ability to jump from a private
struct back to the subchannel struct. Rather than keeping a
copy in our back pocket, let's use the relationship provided
by the vfio_device embedded within the private.
Signed-off-by: Eric Farman
---
drivers/s390/cio/vfio_ccw_
On Thu, 2022-09-08 at 07:19 +, Tian, Kevin wrote:
> ping @Eric Farman.
>
> ccw is the only tricky player in this series. Please help take a look
> in case of
> any oversight here.
Apologies, I had started looking at v1 before I left on holiday, and
only returned today.
&g
On Wed, 2022-07-20 at 17:04 -0600, Alex Williamson wrote:
> On Wed, 20 Jul 2022 17:08:29 -0300
> Jason Gunthorpe wrote:
>
> > On Wed, Jul 20, 2022 at 01:41:13PM -0600, Alex Williamson wrote:
> >
> > > ie. we don't need the gfn, we only need the iova.
> >
> > Right, that makes sense
> >
> >
o/vfio.c | 40 ++---
> --
> include/linux/vfio.h | 4 +-
> 5 files changed, 24 insertions(+), 38 deletions(-)
For the -ccw bits:
Acked-by: Eric Farman
>
> diff --git a/Documentation/driver-api/vfio-mediated-device.rst
e other work in this space. For this series, this is fine.
Reviewed-by: Eric Farman
>
> diff --git a/drivers/s390/cio/vfio_ccw_cp.c
> b/drivers/s390/cio/vfio_ccw_cp.c
> index 8d1b2771c1aa02..af5048a1ba8894 100644
> --- a/drivers/s390/cio/vfio_ccw_cp.c
> +++ b/drivers/s390/cio/v
14 +++---
> drivers/vfio/mdev/vfio_mdev.c | 12
> drivers/vfio/vfio.c | 25 +++--
> include/linux/mdev.h | 1 +
> include/linux/vfio.h | 4 ++--
> 7 files changed, 41 insertions(+), 37 deletions(-)
On Mon, 2022-01-17 at 11:35 -0400, Jason Gunthorpe wrote:
> On Fri, Jan 14, 2022 at 11:30:36AM -0500, Eric Farman wrote:
> > On Fri, 2022-01-14 at 20:28 +0800, Liu Yi L wrote:
> > > Hi Eric,
> > >
> > > Hope you are back from new year holiday.:-) Have you go
s,
> Yi Liu
>
> On 2021/11/30 19:32, Liu, Yi L wrote:
> > > From: Eric Farman
> > > Sent: Tuesday, November 30, 2021 1:18 AM
> > >
> > > On Wed, 2021-11-24 at 12:25 +, Liu, Yi L wrote:
> > > > > From: Jason Gunthorpe
> > >
On Wed, 2021-11-24 at 12:25 +, Liu, Yi L wrote:
> > From: Jason Gunthorpe
> > Sent: Fri, 1 Oct 2021 14:52:51 -0300
> >
> > The css_driver's main purpose is to create/destroy the mdev and
> > relay the
> > shutdown, irq, sch_event, and chp_event css_driver ops to the
> > single
> > created vfi
ce in the vfio_ccw_private and instantiate it as a
> vfio_device when the mdev probes. The drvdata of both the css_device
> and
> the mdev_device point at the private, and container_of is used to get
> it
> back from the vfio_device.
>
> Signed-off-by: Jason Gunthorpe
Rev
On Wed, 2021-10-20 at 19:48 -0300, Jason Gunthorpe wrote:
> On Fri, Oct 01, 2021 at 02:52:41PM -0300, Jason Gunthorpe wrote:
> > This addresses Cornelia's remark on the earlier patch that ccw has
> > a
> > confusing lifecycle. While it doesn't seem like the original
> > attempt was
> > functionally
inter")
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Eric Farman
> ---
> drivers/s390/cio/vfio_ccw_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/s390/cio/vfio_ccw_drv.c
> b/drivers/s390/cio/vfio_ccw_drv.c
> index 76099bcb76
On Mon, 2021-09-27 at 09:32 -0300, Jason Gunthorpe wrote:
> On Fri, Sep 24, 2021 at 04:45:02PM -0400, Eric Farman wrote:
> > On Thu, 2021-09-09 at 16:38 -0300, Jason Gunthorpe wrote:
> > > Having a mdev pointer floating about in addition to a struct
> > > vfio_device
>
On Thu, 2021-09-09 at 16:38 -0300, Jason Gunthorpe wrote:
> This is a more complicated conversion because vfio_ccw is sharing the
> vfio_device between both the mdev_device, its vfio_device and the
> css_driver.
>
> The mdev is a singleton, and the reason for this sharing is so the
> extra
> css_d
On Thu, 2021-09-09 at 16:38 -0300, Jason Gunthorpe wrote:
> Having a mdev pointer floating about in addition to a struct
> vfio_device
> is confusing. It is only used for three things:
>
> - Getting the mdev 'struct device *' - this is the same as
> private->vdev.dev
>
> - Printing the uuid
y: Jason Gunthorpe
> ---
> drivers/s390/cio/vfio_ccw_ops.c | 37 +
>
> 1 file changed, 15 insertions(+), 22 deletions(-)
Reviewed-by: Eric Farman
--
> 1 file changed, 78 insertions(+), 59 deletions(-)
Reviewed-by: Eric Farman
On Tue, 2021-09-21 at 10:19 -0300, Jason Gunthorpe wrote:
> On Mon, Sep 20, 2021 at 08:02:29PM +0200, Cornelia Huck wrote:
> > On Thu, Sep 09 2021, Jason Gunthorpe wrote:
> >
> > > Many of the mdev drivers use a simple counter for keeping track
> > > of the
> > > available instances. Move this co
On Thu, 2021-09-09 at 16:38 -0300, Jason Gunthorpe wrote:
> This addresses Cornelia's remark on the earlier patch that ccw has a
> confusing lifecycle. While it doesn't seem like the original attempt
> was
> functionally wrong, the result can be made better with a lot of
> further
> work.
I though
On Mon, 2021-09-13 at 16:24 -0300, Jason Gunthorpe wrote:
> On Mon, Sep 13, 2021 at 01:40:34PM -0400, Eric Farman wrote:
> > On Thu, 2021-09-09 at 16:38 -0300, Jason Gunthorpe wrote:
> > > This addresses Cornelia's remark on the earlier patch that ccw
> > > has a
52 matches
Mail list logo
