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
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
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
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
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
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
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
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
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
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 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
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
!)
- 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
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
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
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
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
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):
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(+
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_
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
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.
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
> >
> >
ges
>
> Request for testing: I only did build for s390 and i915 code, so it'd
> be nice to have people who have environment to run sanity
> accordingly.
Tested-by: Eric Farman# s390
>
> Thanks!
>
> Changelog
> v2:
> * Added a patch to make vfio_unpin_page
new parameter too.
>
> Signed-off-by: Nicolin Chen
> ---
> .../driver-api/vfio-mediated-device.rst | 2 +-
> drivers/gpu/drm/i915/gvt/kvmgt.c | 19 ++---
> --
> drivers/s390/cio/vfio_ccw_cp.c| 19 +--
>
A
call path, for such a security purpose.
> In
> this patch, add kmap_local_page() to prepare for that.
This all sounds like it's conflating vfio-ccw with vfio-pci, and
configuration-wise I have a hard time picturing the situation described
above. But in the interest of the change in the next
> .../driver-api/vfio-mediated-device.rst | 4 +--
> drivers/gpu/drm/i915/gvt/kvmgt.c | 24 ++---
> drivers/s390/cio/vfio_ccw_cp.c| 4 +--
Acked-by: Eric Farman
> drivers/s390/crypto/vfio_ap_ops.c | 9 +++
>
all
> "pfn_array" strings to "page_array", so as to simplify the code.
>
> Signed-off-by: Nicolin Chen
Reviewed-by: Eric Farman
> ---
> drivers/s390/cio/vfio_ccw_cp.c | 135 ---
> --
> 1 file changed, 64 insertions(+), 71
On Wed, 2022-07-06 at 14:05 -0300, Jason Gunthorpe wrote:
> On Tue, Jul 05, 2022 at 11:27:53PM -0700, Nicolin Chen wrote:
> > This driver is the only caller of vfio_pin/unpin_pages that might
> > pass
> > in a non-contiguous PFN list, but in many cases it has a contiguous
> > PFN
> > list to proces
t
> is actually counterproductive.
>
> Add a pair of simple loops to pass in contiguous PFNs only, to have
> an
> efficient implementation in VFIO.
>
> Signed-off-by: Nicolin Chen
Reviewed-by: Eric Farman
> ---
> drivers/s390/cio/vfio_ccw_cp.c | 70 +
_private.h
> +++ b/drivers/s390/cio/vfio_ccw_private.h
> @@ -98,7 +98,6 @@ struct vfio_ccw_private {
> struct completion *completion;
> atomic_tavail;
> struct mdev_device *mdev;
> - struct notifier_block nb;
Could you also remove this from
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
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 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
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:
> 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
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
--
> 1 file changed, 78 insertions(+), 59 deletions(-)
Reviewed-by: Eric Farman
y: Jason Gunthorpe
> ---
> drivers/s390/cio/vfio_ccw_ops.c | 37 +
>
> 1 file changed, 15 insertions(+), 22 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 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
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
60 matches
Mail list logo
